- From: Peter Geraghty <Peter.Geraghty@tracegroup.com>
- Date: Thu, 3 Sep 2009 09:10:56 +0100
- To: <xmlschema-dev@w3.org>, "Andrew Welch" <andrew.j.welch@gmail.com>
Andrew says 'Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiser'. From the perspective of automated processing of XML this is beside the point. A program processing XML does not look at snippets of markup (and anyway the prefix is not defined by the schema and in a "snippet" without namespace bindings the prefix has no meaning). If a namespace relates to a particular version of a schema, it provides an unambiguous indication of which schema should be used by a processor. If a version attribute has to be considered as well, the processor needs some knowledge of the convention used for versioning within that particular namespace. For this there is no standard. This email chain has brought into new focus a concern I had about the rationale for the Schema 1.1 "Open Content" enhancements. There is an implied expectation behind these that schemas will change without any change in their namespace, and this is arguably not "best practice", since it implies a non-standard versioning mechanism. The idea behind these enhancements is that a message producer can move to a "Level 2" version of a schema, which defines more precisely what in the "Level 1" version would have been possible by use of wildcards, whilst message consumers who are unaware of "Level 2" can continue to process messages from such producers. If the namespace were to change as part of the move from "Level 1" to "Level 2" the intention of the enhancements (that some consumers can remain unaware of the change) would be defeated. I think there is an important consideration that if there many bodies producing messages some may move to "Level 2" while others are at "Level 1". A message consumer may be aware of both "Level 1" and "Level 2" versions of the schema and may need to know which version to apply when processing a message received, e.g., for either or both of the following reasons: (a) The set of messages acceptable under "Level 2" may be smaller than that acceptable under "Level 1". If the processor is responsible for validation, it needs to know which level to use for validation. (b) Typically a "Level 2" schema will have been a response to a need to communicate additional information, and it is a common situation that de facto this information was being sent between parties by means of wildcards under "Level 1". It is likely that the convention for this would not correspond exactly to the formal definitions introduced in "Level 2". Therefore the processor may have to look in different places to find equivalent information depending on which version of the schema the message producer was using. Therefore to be used in an environment where messages are produced by multiple parties and are processed automatically by recipients, the "open content" enhancements imply that some kind of version attribute is available to processors, and to my mind it is a weakness that the schema standard implies versioning changes within a namespace without defining or even mentioning how versioning can be communicated if not by namespace change. Or putting this more strongly, it could be argued that the "open content" enhancements are predicated on "bad practice" in terms of URN assignment. Pete -----Original Message----- From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Andrew Welch Sent: 02 September 2009 16:54 Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiserDisclaimer: The contents of this E-mail plus any attachment is intended for the use of the addressee only and is confidential, proprietary and may be privileged. It will not be binding upon Trace Group or any group company (Trace). Opinions, conclusions, contractual obligations and other information in this message in so far as they relate to the official business of Trace must be specifically confirmed in writing by Trace. If you are not the intended recipient you must not copy this message or attachment, use or disclose the contents to any other person, but are requested to telephone or E-mail the sender and delete the message and any attachment from your system. Trace takes all reasonable precautions to ensure that no virus or defect is transmitted via this e mail, however Trace accepts no responsibility for any virus or defect that might arise from opening this E-mail or attachments.
Received on Thursday, 3 September 2009 09:39:02 UTC