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 > [email protected] > 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 [email protected] http://kwarc.info/kohlhase ----------------------------------------------------------------------
<<attachment: m_kohlhase.vcf>>
_______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
