foreign content in unitsml

["Martin S. Weber" <martin.weber@nist.gov>]

(this was to be recorded as part of the asynchronous portion of the May
13 UnitsML meeting which officially never happened so now it is to be recorded 
as part of the asynchronous portion of the June 17 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