OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: foreign content in unitsml


(this is to be recorded as part of the asynchronous portion of the May  
13 UnitsML meeting)

as I have announced earlier on, I want to give some examples of prior  
art of attribute-only vocabularies as well as how other markup  
languages handle alien content.

Attributes: before giving examples (of which I sadly did not find as  
many as I wanted to), I want to remind you of basic possibilities in  
XML to associate some information with a given element E. The first  
possibility is to add another element F which refers to E via its  
(xml:)id, or via an XPath expression, preferrably the former. All the  
necessary information then is put as child nodes of F, although  
logically it belongs to E, albeit outside E's language's intended  
domain. This is somewhat awkward for small bits of information. An  
alternative, preferrably for simple bits of information (one or two or  
few additional traits) is to extend E's attributes to carry the  
necessary information. And as God has giveth the namespaces, they can  
be used to clearly signal that the additional information is outside  
the intended domain of use of E's native language.

Examples of this include xml:id, xml:space, and generally all efforts  
of the "XML Linking Working Group" which includes the TRs "XML Linking  
Language", "XML Base" and "XML Pointer Language". Their critical, or  
all of their information items are put into attributes attached  
directly on the elements to be annotated/extended. All of these  
information items lie within well-defined namespaces.

I do not think there is anything wrong in allowing users of UnitsML to  
extend the information which we think they should/would want to store  
by using the 'cheap' way out - of adding attributes not living within  
the empty or unitsml namespace. Extensibility as such is not  
achievable without rewriting schema components if we do not offer it.  
I.e. if someone was to import unitsml into their own schema, they  
would need to rewrite parts of our element definitions to allow  
annotation with alien attributes, which in my opinion is an  
unnecessary hindrance for use of UnitsML.

Similarly I think of elements which live in other namespaces than that  
of UnitsML. An Example coming to mind are the TRs of the "XML Security  
Working Group", namely "XML Signature" which adds elements for the  
signature of content. Now it's debatable whether that should happen by  
creating a new schema which imports xml-sig as well as unitsml and  
merges them, so that signed content will adhere to that new schema, or  
whether it is fine for the content to just validate against the  
unitsml schema and just happen to care another element or two  
containing the signature and description of how it was signed. But  
again, I don't think there is a clear canonical way to do it, and I  
don't consider it wise to force UnitsML users into a specific way of  
doing it.

Also given we were talking about OpenMath earlier, here is what they  
write in their specification, as an alternative approach to allowing  
foreign content in openmath: "When embedding XML encoded OpenMath  
objects into a larger XML document one may wish, or need, to use other  
XML features. For example use of
extra XML attributes to specify XML Namespaces or xml:lang attributes  
to specify the language used in strings.

If such XML features are used then the XML application controlling the  
document must, if passing the OpenMath fragment to an OpenMath  
application,
remove any such extra attributes and must ensure that the fragment is  
encoded according to the schema specified above." (OpenMath standard  
2.0 Section 3.1.3 'Embedding OpenMath in XML Documents')

To sum up: I don't think it hurts us but opens up more possibilities  
for potential users if we allowed:
- any attributes of any foreign namespace anywhere
- any elements of any foreign namespace anywhere
and/or potentially stated something along the lines of the OpenMath  
quote above.

-Martin


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]