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

[David Carlisle]

On 30/04/2014 08:23, Lars Hellström wrote:
> Michael Kohlhase skrev 2014-04-23 15.24:
>> Dear all,
>>
>> In thinking about OpenMath3, we have problem that there are some
>> language extension proposals, but at the same time, we have the
>> problem that we have to keep MathML3 compatibility.
>
> No, we don't (as far as OM3 is concerned); that Unicode 1.1 became
> ISO/IEC 10646-1:1993 didn't prevent the creation of Unicode 2.0
> (which introduced notable features such as surrogate pairs). It may
> still be desirable to stay compatible with MathML3, but it cannot be
>  an a priori limit on the evolution of OpenMath.


It's true that MathML doesn't necessarily constrain OpenMath (but it
might:-) but I don't think the Unicode example is relevant. The Unicode
and ISO standards are kept (more or less) in step and overseen by the
same technical committee, so basically that example is just saying that
standards can be updated, just as we have MathML3 following 2 and
OpenMath 3 probably following OpenMath 2.

So coming back to OpenMath/MathML, structurally it is _highly_ unlikely
that there will be a revised MathML standard anytime soon. Even if we
started to re-charter a group to revise the standard now it would be a
couple of years to go through the process, and in fact there are no
plans to re-charter (and the current working group has been extended to
2016).

So the OpenMath Society should consider MathML3 as essentially a fixed
thing. We can choose whether that affects us or not, it does not have
to, but one of the possible aims in the list that Michael listed when
kicking off this process in Bath was to have a new OpenMath encoding
using MathML rather than the "traditional" OpenMath namespace OMA etc.
If we make that a design aim that does constrain any extensions to be
encodable in MathML3. "encodable" might involve some work, it doesn't
imply there has to be a 1-1 element mapping, but it probably ought to
be lossless and reversible to count as an "encoding" that is: any MathML
that is used to encode the new constructs can not also be read as
encoding existing constructs. But we don't _have_ to do this, it may be
that not all the desired things are required (or in fact desired when
examined more closely).


>
> 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.

>
> 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.....

David