RE: [ubl] Proposed withdrawal of my NDR suggestions for ABIE extensibility

["Sylvia Webb" <swebb@gefeg.com>]

Hi Ken,

Does this mean that there can be no future minor versions of UBL 2.0?

Regards,
Sylvia

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Tuesday, June 20, 2006 7:56 AM
To: Universal Business Language
Subject: [ubl] Proposed withdrawal of my NDR suggestions for ABIE
extensibility

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/ExtendingAndVersioningX
MLLanguages.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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php