[om] A Proposal for extending OpenMath with XML annotations

[Andreas Franke]

> A bit of clarification about the 'extending' the OMSTR I
> proposed is in order. I was not implying to allow for
> example <bla><foo></bla> inside an OMSTR. 

I assume you meant to write <foo/> in the above example.
So you are saying that in your original example you 
intended to write 

  <OMSTR> &lt;mrow&gt; &lt;mo&gt;sin&lt;/mo&gt; &amp;ApplyFunction; ...
  </OMSTR>

instead of what you wrote there:

> <OMSTR> <mrow> <mo>sin</mo> &ApplyFunction; <mn>1</mn> </mrow> 
> </OMSTR>

But then I don't understand your remark about the entity reference:

> Note however that the entity reference here has to be resolved
> as this would introduce another problem. This because the 
> standard explicitly forbids them (OMStd Sect. 4.1.1).
 
If &amp;ApplyFunction; is what you write for the entity reference,
then this is a non-issue, isn't it?

> But on the object level
> have a convenience method that would allow you to
> get the stored string back as an DOM object.
> 
>   Eg. omString.getAsDOM()

This would basically be the same as providing a ParseXML function
which could then be used as ParseXML(omString.get()) , wouldn't it?
(Note that this would have to generate exceptions in the case that
the content of the OMSTR is not well-formed XML.)

I don't have a problem with providing convenience functions to
parse XML strings, but then again we are talking about _descriptions_
of XML fragments in the XML representation of an OMOBJ, not about
embedded foreign XML on the same level as the surrounding XML.
If this indirection is acceptable, then using <OMSTR> is fine.

However, Stephen's original examples were both of the latter form 
where the embedded XML was on the same level as the OMOBJ. I suppose
his goal was to allow existing XML-processing tools to manipulate 
both the OpenMath elements as well as embedded foreign elements
in one step, without converting back and forth between strings and
the DOM:

> The approach of the "altenc" cd is too primitive
> (converting the XML to strings, e.g. "&lt;sin/&gt;") because it
> does not allow tools to manipulate the XML data. 

I can't see how your proposal helps here, since generic XML 
processing tools won't be able to make use of any OpenMath-
specific getters like omString.getAsDOM().

Cheers,
Andreas


--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems