[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: foreign content in unitsml
(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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]