Proposed withdrawal of my NDR suggestions for ABIE extensibility

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

Hello all,

Based on the Pacific call discussion of the 
dangers of opening up uncontrollable 
extensibility in all ABIEs, and on Bryan 
Rasmussen's (much appreciated, Bryan, thanks!) 
research and findings in the area of schema 
determinism, I think it is safe to take my 
discussion of minor versioning off of the agenda tomorrow.

I now do not see a way of providing minor version 
extensibility using W3C Schema syntax.

In private correspondence (thanks Fraser!) the 
following article by David Orchard on 
extensibility was brought to my attention:

   http://www.pacificspirit.com/Authoring/Compatibility/ExtendingAndVersioningXMLLanguages.html

Reviewing David's rules:

  1.  Allow Extensibility rule: Languages SHOULD be designed for extensibility.

This is laudable, but because UBL has four 
distinct namespaces, I don't believe this can be 
done at the ABIE level using W3C Schema syntax 
(though I believe it could be done using 
RELAX-NG).  We are already covered at the 
extensibility point.  But this is moot given the other analysis below.

  2.  Allow Extensions in Other Namespace rule: 
The extensibility point SHOULD at least allow for 
extension in other namespaces.

We do have an extensibility point and we do allow 
for other namespaces, so I think this is covered.

  3.  Full Extensibility rule: All XML Elements 
SHOULD allow for element extensibility after 
element definitions, and allow any attributes.

Because we have four namespaces in UBL I cannot 
see how to do this in W3C Schema syntax.

  4.  Provide Processing Model Rule: Languages 
SHOULD specify a processing model for dealing with extensions.

In my discussion paper, the chapter on 
deployments illustrates a 
"translate-before-validate" step that addresses 
this.  Using that an application never sees the 
unexpected use of extensions (but it also doesn't 
see inappropriate uses of extensions that are not 
important to the application).

  5.  Must Ignore Rule: Document consumers MUST 
ignore any XML attributes or elements in a valid 
XML document that they do not recognize.

This is covered by translate-before-validate.

  6.  Must Ignore All Rule: The Must Ignore rule 
applies to unrecognized elements and their 
descendents in data-oriented formats.

This is covered by my suggested use of ##skip 
instead of ##lax so as to totally ignore all 
descendants of the extension point, even if an 
extender chooses to reuse a UBL construct.

  7.  Must Ignore Container Rule: The Must Ignore 
rule applies only to unrecognized elements in presentation-oriented formats.

UBL doesn't allow mixed content, so I believe the above isn't an issue.

  8.  Re-use namespace names Rule: If a backwards 
compatible change can be made to a specification, 
then the old namespace name SHOULD be used in 
conjunction with XML’s extensibility model.

This is supported in my earlier suggestion that 
we do not change the namespace for information items defined earlier.

  9.  New namespaces to break Rule: A new 
namespace name is used when backwards 
compatibility is not permitted, that is software 
MUST break if it does not understand the new language components.

This would contradict my suggestion that 2.1 
information items use a new namespace.  David's 
opinion would be, then, that as long as 2.1 
information items are backwards compatible they 
continue to use the same namespace, and only if 
the introduction of a new construct requires 
something not allowed by the prior namespace, 
that it have a new namespace.  Since my proposed 
translate-before-validate covers this, we are 
okay to keep the 2.0 namespace for 2.1 
constructs.  I can live with that just fine and 
abandon my suggestion for a new namespace for new 2.1 constructs.

10.  Provide Must Understand Rule: Container 
languages SHOULD provide a “Must Understand” 
model for dealing with optionality of extensions 
that override a default Must Ignore Rule.

I'm not proposing that extensions override the 
must ignore rule, so I don't think this applies.

11.  Be Deterministic rule: Use of wildcards MUST 
be deterministic.  Location of wildcards, 
namespace of wildcard extensions, minOccurs and 
maxOccurs values are constrained, and type restriction is controlled.

It appears my original suggestions did not follow 
Rule 11, as pointed out by Bryan, so we can't 
have what I thought we needed at the ABIE level.

Conclusion:

So ... based on a read of David's article, I'm 
now of the opinion there are no changes to make 
to the NDR.  Given that all new UBL 2 constructs 
are optional, then the translate-before-validate 
approach guarantees a must-ignore attitude by downstream applications.

Because of our use of four namespaces for UBL 
constructs, I believe we cannot use W3C syntax to 
control ABIE-level extensibility, so we stick with the one extensibility point.

My suggested translate-before-validate will 
address Jon's concerns about an implementation 
not falling over dead when it sees a new 
construct (because it actually never ends up seeing the new construct).

It does mean that Paul's concerns are not being 
met as expressed in Brussels regarding a network 
deployment of heterogeneous schema validators all 
indicating UBL 2 namespace for instances will 
fail on 2.1 instances using the UBL 2 namespace 
unless they do their own 
translate-before-validate ... which, as noted 
above, will create some false positives if the 
translation throws away non-conformant constructs 
resulting in a conformant instance.

Thanks again to the feedback regarding my 
straw-man proposal for versioning ... it has 
helped me understand a lot, and I hope it was 
considered constructive even if it has to be removed.

My discussion of UBL Customization in my paper 
still stands, though ... I will revise my 
discussion paper to remove the discussion of minor versioning.

Now, my question is, does anyone disagree with 
this analysis and feel we should not remove this 
discussion from the agenda and keep talking about it?  :{)}

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

--
Registration open for UBL training:    Montréal, Canada 2006-08-07
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal