Re: [ubl-dev] Re-examination of W3C Schema techniques formodifying base UBL

[stephen.green@systml.co.uk]

That's an excellently worded critique I think Ken

I must agree that these W3C XML Schema derivation methods,
in view of the limitations and the complexity overheads,
really don't seem to give us anything convincing enough.
Like Ken I just question what would be achieved. In
particular there is little point, it now seems to me, in
the restriction use (other mechanisms give more with less)
and for extension UBL 2 soon offers extension points with
the key benefit that an instance only has to validate
against the standard schemas.

I felt we really needed this exhaustive appraisal Joe has
facilitated and others have so well contributed to - some
excellent wordsmithing and clear thinking in there. Thanks
very much indeed to all who chipped in. Now, although there
may well be more to be said, I feel there is plenty on the
record to help provide background for the considerations
of the UBL TC and implementers and advisors.

Of course, for those wishing to use substitution groups to
customise UBL schemas there is the global design to help in
UBL 2, but those who do should do so aware of the limitations,
consider whether they * should * be republishing under a UBL
namespace (perhaps they shouldn't), and give careful thought
to what they might and might not achieve and whether it is
better achieved and more besides in a differnet way.

Excellent.

All the best

Steve


Quoting "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
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing 
> the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>