Re-examination of W3C Schema techniques for modifying base UBL

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

I want to take the time to laud the efforts of Steve and Joe at 
trying to come up with W3C Schema-based schemes of customization ... 
but in my tests after the release of UBL 1 I was unable to do get 
beyond what I believed are restrictions in the W3C Schema concepts of 
restriction and extension to apply to the UBL scenario.  That isn't 
to say they are bad for other database or object-oriented objectives 
of restriction and extension ... I'm just talking UBL.

In fact, I thought I was there for UBL but I discovered I was using a 
faulty schema validation tool that incorrectly reported my use of 
redefine as working, and moving to a conforming validation tool 
revealed it as not working at all.  It seems I cannot find this in 
the archives but will keep on looking.

At 2006-05-12 16:30 -0600, stephen.green@systml.co.uk wrote:
>I still prefer Schematron layered over the original standard UBL schemas.

Indeed ... I think it has been determined that with code list value 
validation a single pass is not going to address the needs of the 
user community ... so if we are already looking at layers, there may 
not be a lot of benefit exhausting W3C techniques until one might be 
found that the standard forces to be obtuse and difficult to use 
(though, granted, that isn't a worry of the end user if it is 
implemented behind the scenes).

But I do appreciate these efforts are confirming what I believed the 
W3C Schema technology could not do for us in our scenario.

>It sounds like quite a few voices here are saying the same.

I certainly do, and I'm questioning what is the purpose of the 
redefine and substitutions that are being attempted?  Are you trying 
to come up with customization mechanics for defining extensibility of 
UBL by trading partners (say for additional document detail 
information items), or for defining restrictions of UBL for 
communities of users (say for directing editing tools)?

We are looking at the use of the "any" concept for additional detail 
(it might be useful to explore W3C Schema techniques for extending 
the "any" element ... both by one user and "layered" by multiple 
definers of extensions ... say one for the aerospace industry and 
then a layer on top of that for Boeing).

The developers of authoring tools should have user interface 
facilities to limit the amount of a schema that is presented to the 
end user.  Are concerns by list members about restricting UBL for 
authoring misplaced?  Why try to change the definition of UBL by the 
schemas when one can just limit the user interface to only present 
the user with the ability to add content to the subset defined by the 
XPaths?  Then you are following the XML vocabulary model of not 
touching the model constraints and still creating valid UBL .. all 
you are doing is restricting what gets added to the instance through 
mechanisms in the authoring tool.  Surely this is the parallel to a 
database export creating a UBL instance and directing the export to 
only populate fields within the subset.

There isn't ever any need to massage or change the data models of UBL 
in any way and synthesize any kind of schema expression from the 
changed models ... I see those as totally sacrosanct after delivery, 
and the normative read-only schema expressions for UBL should be the 
only schema expressions used by tools ... in this way the foundations 
of UBL and the expressions of UBL are globally accepted and unchanged 
and all methods of using UBL in scenarios are isolated to layers on 
top that can be negotiated between users.  Thus, "base UBL" is always 
ever the same and is something we can all build on, and there would 
be no confusion by changing models or schema expressions.

I sincerely believe this viewpoint will garner a lot of long-term and 
inexpensive support for UBL, much like using "base HTML" initiated 
long-term and inexpensive support for hypertext with standards such 
as CSS layered on top to add functionality without touching the 
base.  When vendors attempted to modify the data models of HTML 
adding their own custom elements there were interoperability issues 
with servers not getting the information they needed thus requiring 
pages to include "this page must be viewed by (name your browser here 
with your custom extensions)" icons on the screens?

I strongly believe the data model and the schemas we produce from it 
should be untouchable and we should only promote layering ... thus 
learning from the mistakes of vendors for the web and showing from 
day one that successful layering techniques proven elsewhere are the 
modus-operandi for UBL.

(I'll get off my soapbox .. sorry to be so long-winded this morning 
... I had a good sleep).

Perhaps after such deep spelunking into the depths of W3C Schema we 
should re-examine the objectives of what we'll be doing with the 
mechanisms when they are discovered.  We might find we don't need 
them after all.

Thanks again for all your efforts, Stephen and Joe,

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

p.s. I'm off list for 48 hours so I'll check any responses when I return.

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSLT/XSL-FO training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal