Re: [xml-dev] Will XML Schema 1.1 get traction?

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2012-08-14 16:11 +0100, Andrew Welch wrote:
>On 14 August 2012 15:57, John Cowan <cowan@mercury.ccil.org> wrote:
> > Rick Jelliffe scripsit:
> >
> >> I have reached the stage where I think every enumerated list in an XSD
> >> (or RELAX NG, or DTD) should be regarded as guilty until proven
> >> useful, unless they are stable and unlikely to change in the lifetime
> >> of a schema.
> >
> > I agree in principle.  However, such constructs may be not so much a
> > schema smell as an organizational smell.  Excluding lists from schemas
> > presumes that someone else is in the business of making and validating
> > them
>
>I don't really see a problem with holding the enumerations in a file
>of their own and versioning them separately to the main xsd.  That's
>no different to external code lists, and it avoids the separate
>additional validation step.

The OASIS Universal Business Language TC ended up deciding there was 
a difference between embedding code lists and externalizing 
them.  Sadly, UBL 2.0 ended up with a hybrid of embedded (from 
UN/CEFACT schemas) and externalized (from UBL TC schemas) code lists 
and from version 2.1 all are now external.

The OASIS Code List Representation TC published Tony Coates's 
genericode specification and my context/value association 
specification as the combination used to create the separate 
additional validation step you cite.  Users use these to create 
expressions of their code list requirements, and a process creates 
the runtime artefacts for validation.  These specifications are not 
reserved for UBL, as they work with any XML vocabulary.  They are 
based on XDM and XPath, not on XSD.

In UBL, the XSD expressions are normative and the second-pass 
value-validation expressions are not normative.  Every trading 
partner community, or even a single trading partner relationship, may 
have differing value-validation requirements, but the UBL XSD 
expressions are fixed.

The real-world scenario that finally demonstrated the problem with 
UBL 2.0 having embedded the UN/CEFACT currency code list is that 
Turkey changed their currency symbol a couple years after it was 
published.  Users with that requirement cannot use UBL 2.0 
unchanged.  UBL 2.1 (and future versions) schemas handle this change 
and future changes in value validation by recognizing the structural 
and lexical constraints on a UBL document are inviolate, while the 
value constraints are likely to be very fluid in a business context 
(and likely others as well).

I have heard the argument that those XSD files with code lists can be 
managed separately from those XSD files with structure and lexical 
constraints, but that doesn't address (from a standards committee 
perspective) that "the published normative schemas are 
standardized".  Anyone claiming that their instance is UBL-conformant 
(regardless of their value constraints and their imposed subsetting 
of the UBL optional stuff and their imposed extensions at the 
standardized extension point) can always have their claim validated 
by going to the committee repository and downloading the schemas and 
use them unchanged without any validation errors.

They won't be able to do that if XSD 1.1 is used to express 
enumerations and other value constraints that are fluid for users.

Whether XSD 1.1 is needed otherwise for structural and lexical 
constraints remains to be seen, but I don't think there are 
requirements yet expressed that require us to explore that now.  XSD 
1.0 seems expressive enough for the simple relationships that exist 
from having used ISO/IEC 15000-5 Core Component Technical 
Specification as the modeling methodology.

I hope this helps.

. . . . . . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Oct 2012
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/x/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal