[Om3] Language Dictionaries (Was: Re: Initializing OM3 at 2013 Process)

Michael Kohlhase m.kohlhase at jacobs-university.de
Fri May 2 19:28:04 CEST 2014


Dear all,
On 1.5.14 12:11, David Carlisle wrote:
>
>>
>> I understand EdNote2 as saying that this particular FMP is
>> superfluous, as it would anyway be implied by a similar FMP in the
>> argseq CD. I tend to agree, but note that could well be properties of
>> new notation that isn't as natural to state for ordinary symbols.
>>
>>> <translation cd="argseq">
>>
>> Now this is the really heavy part of the proposal, but also that part
>> which is most vaguely explained. Is this supposed to be XSLT, or
>> something homegrown inspired by the same?
>
> Yes I must admit that my first thoughts were similar. I'm not convinced
> that the community is big (or strong) enough to have a mechanism for
> introducing new elements and a transformation pipeline. It is always
> possible to have specific local elements for "in house" processing but
> then transform using an off-the-shelf technology such as xslt to
> "standard" openmath or mathml (or something else entirely). So having a
> custom transformation process (and then requiring anyone receiving the
> openmath can execute that) is quite a high risk strategy.
Actually, I was hoping that some few language extensions would be adoped
by OpenMath and implemented by the community, since they are considered
useful. Then the these transformations would not have to be executed at
all. I view their purpose as similar to the pragmatic-to-strict
transformation in the MathML3 recommendation.

That being said, we could also use well-behaved XSLT if that made the
proposal more palatable. We would also have have the translations have a
CMP part (human-readable transformations like in MathML3) and a FMP part
(executable XSLT). \
>
>>
>> A problem with this example is that it seems to be aimed at showing
>> off the file format (which at this point must be considered very
>> preliminary) rather than the underlying mechanism; the translations
>> it performs are very trivial -- changing <OMNATS> to <OMA><OMS
>> cd="seqs" name="nats"/> and so on could equally well be done by
>> substring replacements! -- and the language extension achieved is
>> highly uncompelling. Having special elements for straightforward
>> combinations of OMA and OMS gains practically nothing, but the cost
>> in increased language complexity is considerable.
>
> That was my initial thought as well, but perhaps more examples would be
> more convincing.....
I would be happy to do more examples once we agree that language
extensions are an avenue worth exploring in principle.

Michael
>
> David
>
>
> _______________________________________________
> Om3 mailing list
> Om3 at openmath.org
> http://openmath.org/mailman/listinfo/om3

-- 
----------------------------------------------------------------------
 Prof. Dr. Michael Kohlhase,        Office: Research 1, Room 168
 Professor of Computer Science  Campus Ring 1, 
 Jacobs University Bremen           D-28759 Bremen, Germany
 tel/fax: +49 421 200-3140/-493140  skype: m.kohlhase   
 m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase 
----------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: m_kohlhase.vcf
Type: text/x-vcard
Size: 332 bytes
Desc: not available
URL: <http://openmath.org/pipermail/om3/attachments/20140502/f259fbeb/attachment.vcf>


More information about the Om3 mailing list