[Trac] [OpenMath] #118: Clarify CDDefinition/@xml:id (should have same content as Name)

[David Carlisle]

On 08/04/2010 12:48, OpenMath wrote:
> But when the client requests
>   application/openmath+xml (to be specified, see
>   #106) or suppose application/rdf+xml or
>   whatever from that URI, the server serves the content dictionary source,
>   or
>   RDF/XML, or something else.

if they get the actual cd file then it is the responsibility of the CD 
reading application to know the CD format and so treat Name as the ID of 
each definition.

Similarly, if you are generating rdf on the server, just as when you 
generate xhtml on the server, that generating software needs to know the 
CD format and do whatever is necessary in the RDF, just as it does when 
it generates XHTML. No change to the CD format is needed for this to happen.



as most XML libraries have immediate support for retrieving an element by
  its
  xml:id – as opposed to retrieving `//CDDefinition[Name = $fragment-id]`.


If you are using xpath the difference between

//CDDefinition[Name = $fragment-id]

and

//CDDefinition[@xml:id = $fragment-id]

is rather slight. (Other variants such as using key() or id() would be 
or could be identical, as they intentionally hide the differences in 
source markup behind a function call)


  But then we are still missing one little thing in the OpenMath spec,
  which I propose for version 3.  We have to explicitly say:  "If a fragment
  with
  ID f has to be located in an OCD XML document, the answer is the
  CDDefinition
  element whose Name child has the text content f."

but that is there in OpenMath 2 already:

Canonical URIs for Symbols
To facilitate the use of OpenMath within a URI-based framework (such as RDF
[19] or OWL [18]), we provide the
following scheme for constructing a canonical URI
for an OpenMath Symbol:




     URI = cdbase-value + '/' + cd-value + '#' + name-value



 > Just for curiosity:  Is
  anybody
  really _using_ the CDs for anything related to MathML?

probably not yet, but MathML3 isn't even fully baked yet.
However they are used extensively by MathML itself, underpinning all the 
content elements in chapter 4.


 >  so then the only step that remains is removing xml:id ASAP.

there were some speculative suggestions towards a modified OM3 CD format 
at the start of the mathML3 cycle, but in practice it turned out that 
only a few very small additions to the existing CDs were needed (and no 
change to the format) these were agreed at the OM meeting in Canada last 
year. Given that fact and the MathML3 spec is about to be standardised 
using a very tight binding to the OM2 Cds, personally I'd rather we just 
flagged the OM3 CDs as an experimental branch not under current 
development, and for the immediate future build developments on the 
existing standard (new cds, better translation to rdf, xhtml, owl or 
whatever). Of course nothing is fixed for ever, and if new requirements 
come up that require a new CD format we should make one, but any new 
requirement would on the face of it apply equally to Content MathML, and 
having spent 5 years not quite finishing mathML3, then we're presumably 
not going to make a revised MathML 3+x for a while.

David












________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________