RE: Best Practices for Establishing Namespace Name

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