[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Changing Namespaces Between Specification Versions

• From: "G. Ken Holman" <gkholman@C...>
• To: xml-dev@l...
• Date: Wed, 22 Apr 2009 22:07:12 -0400

At 2009-04-22 21:54 -0400, Webb Roberts wrote:
>On Wed, Apr 22, 2009 at 3:17 PM, Chuck Bearden <cbearden@r...> wrote:
> > [...]
> > The decision was made (a) to add a version attribute to the root element,
> > and (b) not to change the namespace URI (which was already unversioned).
> >  Did the maintainers of EgXML make the right choice?
>
>What happens when a message needs to be constructed, exchanged, and
>validated, which contains content defined by both v1 and v2? A
>majority of schema-validating XML parsers support only a single schema
>for a given namespace on a particular validation pass.

If the content is defined by both v1 and v2 then it doesn't matter 
which schema is used, either one will work.

OASIS Universal Business Language (UBL) keeps the same namespace for 
minor versions and requires new constraints in later versions not to 
render any instance of an earlier minor version as invalid.  For 
example, new minor versions only introduce optional constructs so as 
not to make an existing instance invalid because of their absence.

A system only supporting older instances strips unexpected constructs 
from newer instances before validation, such that validation will 
allow content to be processed by APIs that require validation to the 
older schema.

An element in instances contains the version number the instance 
creator is using for the selection of the constructs.  But it is just 
informational and is not a schema value constraint, because then a 
newer system wouldn't be able to accept an older document even though 
the older document doesn't violate any constraints (because the newer 
constraints are all optional).

>What happens when a message is constructed that only uses content from
>v1 or v2, without using the designated root element?

Then how can it validate with either version if the document element 
isn't in either schema?

>How does the
>receiver determine the appropriate schema when the version is not
>explicitly referenced?

Why not "try one and if it fails try the other"?

Or make the version mandatory and fail if it isn't present.

The business rules around working with an instance form part of the 
processing rules for the instances.  Those should be documented for systems.

I hope this helps.

. . . . . . . . . . Ken

--
XQuery/XSLT/XSL-FO hands-on training - Los Angeles, USA 2009-06-08
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@C...
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

• Follow-Ups:
  • Re: Changing Namespaces Between Specification Versions
    • From: Andrew Welch <andrew.j.welch@g...>

• References:
  • Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: "Paul Spencer" <xml-dev-list@b...>
  • RE: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: "Michael Kay" <mike@s...>
  • Re: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: "Pete Cordell" <petexmldev@c...>
  • RE: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: "Michael Kay" <mike@s...>
  • Re: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: Andrew Welch <andrew.j.welch@g...>
  • Re: Changing Namespaces Between Specification Versions (was: XIN: XML implicit namespace definitions)
    • From: "Pete Cordell" <petexmldev@c...>
  • Re: Changing Namespaces Between Specification Versions
    • From: Chuck Bearden <cbearden@r...>
  • Changing Namespaces Between Specification Versions
    • From: Webb Roberts <strebor@g...>