XML Namespaces & Extensibility

[Jesse McGatha]

XML Namespaces & Extensibility – The extensibility strategy for AMF (add whatever elements/attributes you desire) seems in conflict with the goal to be future compatible. If a major document producer were to start creating a large, widely-distributed corpus of documents containing extension elements in the default namespace, this would necessarily constrain future development of the spec. I’m curious why there is not a requirement that all non-standard elements and attributes must be introduced in a different namespace than that of the standard itself. It would also be helpful to define the default namespace explicitly.

[Hod Lipson]

 

XML Namespaces & Extensibility – The extensibility strategy for AMF (add whatever elements/attributes you desire) seems in conflict with the goal to be future compatible. If a major document producer were to start creating a large, widely-distributed corpus of documents containing extension elements in the default namespace, this would necessarily constrain future development of the spec. I’m curious why there is not a requirement that all non-standard elements and attributes must be introduced in a different namespace than that of the standard itself. It would also be helpful to define the default namespace explicitly.

 

Extensions to AMF would always need to be approved by the ASTM committee. It is technically simple to extend XML, which is convenient and one of the reasons we chose XML. But that does not mean that every change automatically becomes part of the official standard.

 

If there is a way to word this better, then let’s change the text…

 

--hod

 

 

 

--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To view this discussion on the web visit https://groups.google.com/d/msg/stl2/-/H29TD2NWmygJ.
To post to this group, send email to st...@googlegroups.com.
To unsubscribe from this group, send email to stl2+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/stl2?hl=en.

[Jesse McGatha]

On Friday, January 11, 2013 10:51:44 AM UTC-8, Hod Lipson wrote:

 

Extensions to AMF would always need to be approved by the ASTM committee. It is technically simple to extend XML, which is convenient and one of the reasons we chose XML. But that does not mean that every change automatically becomes part of the official standard.

 

While that may be what was intended, that is not at all what the spec leads a reader (at least this one) to believe.

 

Specifically, it says, in 3.1.6: "this file format is easily extensible... [and] allows new features to be added as advances in technology warrant" without ever stating that additions by producers (as opposed to the F42 committee) are prohibited, even though producers are typically the source of advances in technology. I grant that it is subtly implied, but the use of passive voice in this section obscures the subject of the sentence (an example of ambiguity in the spec), that this section is in fact referring to F42.

 

However, that implication is pushed to the opposite interpretation that extensibility can be implemented independently by producers/consumers because of the text in section 4.4: "Additional XML elements can be added provisionally to any AMF file for any purpose but will not be considered part of this specification. An unofficial AMF element can be ignored by any reader and does not need to be stored or reproduced on output. An element becomes official only when it is formally accepted into this specification."

 

This statement is problematic in several ways:

 

1) It never states who can add the provisional content to an AMF file... Only producers add content to files (but not the spec). Only F42 can add provisional elements in the spec (but not files).

 

2) There is no reason for F42 to distinguish between provisional content (whatever that means... presumably it means a new draft of the spec... it certainly isn't defined). It seems nonsensical for the spec to talk about "official" and "unofficial" elements.  Either the spec is accepted or it is a draft. It would be best to use this kind of language.

 

3) Nor is there reason to define what consumers (readers) should do with such "unofficial" elements. A file is authored against a particular version of the spec, in which case the consumer can already unambiguously resolve the meaning of elements in context of the spec, according to the version of the spec that the consumer was authored against.

 

The implication of much of this language, particularly talking about adding these to files, strongly implies that producers can author AMF files with "foreign" elements and attributes for their own independent extensibility purposes. It also implies that this is a course for proving out the viability of a certain extended features, before being folded back into the spec "officially".

 

Without question, one of the key benefits of an XML format (allowing a single producer/consumer to innovate by storing data in the file format) without impacting other consumers because of the parsing syntax afforded by the XML spec. This leads one to believe that the spec is making a statement to explicitly allow producers to make such extensions.

 

For me personally, this confusion was further exacerbated by conversations with other F42 members that explicitly stated that such extensions were possible ("because it is XML, you can add new elements or attributes"). Indeed, this was understood to be an important selling point of the format, unlocking innovation potential by individual producers/consumers. Clearly, the spec is not clear, even among members of the committee and deserves clarification.

 

All that being said, there is tremendous value in enabling formalized extensibility by producer/consumer value chains. However, it is necessary to then formally define how such elements could be added. XML Namespaces are an excellent way of providing this.

 

Finally, AMF as XML could be embedded in a larger XML document and therefore should formally define a namespace to allow documents that embed this content to write valid schemas, regardless of the resolution of the ambiguity above.

 

Thanks for hearing me out.

 

[Jesse McGatha]

As requested on another thread, I wanted to re-raise this issue about XML Namespaces. It would be good to define the namespace URI of the AMF XML markup, e.g. something like http://schemas.astm.org/amf/1.2. It would also be highly useful to define an interoperability namespace as well, for purposes of transforming AMF data into metadata in other formats' metadata, thus allowing faithful AMF->FormatX->AMF transformations.

 

-Jesse

[Hod Lipson]

AMF namespaces are define in the next revision. Now under review at ASTM and ISO simultaneously.

The exact URI is still undefined, but will probably be something like you suggest.

--hod

 

 

Hod Lipson

Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science

Cornell University, 242 Upson Hall, Ithaca NY 14853, USA

Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222

Email: Hod.L...@cornell.edu

Web: http://www.mae.cornell.edu/lipson

Administrative Assistant:  Craig Ryan  cd...@cornell.edu

Calendar: http://www.mae.cornell.edu/lipson/calendar.htm

--

You received this message because you are subscribed to the Google Groups "STL 2.0" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.

To post to this group, send email to st...@googlegroups.com.

Visit this group at http://groups.google.com/group/stl2.
For more options, visit https://groups.google.com/groups/opt_out.