RE: [ubl-dev] SBS and Restricted Data Types

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

At 2006-05-04 10:42 -0400, Chiusano Joseph wrote:
>Yes, one has to provide a developer (or auto-generation tool) with both
>subset definition and the parent schemas. My guess is (not having
>examined it in detail recently) one has to do this anyway, unless there
>is reason to
>combine all the schema information into the subset definition   :-(
>
>[JMC] Comment on both responses above, and speaking only for W3C Schema:
>Given that W3C Schema already has features such as extension and
>redefine that are supported by many tools today, at what point does the
>"methodology extension" referred to above begin to re-invent what W3C
>Schema already allows?

Because (1) the objective of the subset is not to create another 
schema ... applications still have to accept and validate a complete 
UBL instance according to the normative UBL W3C Schema expressions, 
and they will have to generate instances that validate against the 
normative W3C Schema constraints ... the subset only describes how 
much of instances described by the W3C Schema constraints are 
considered meaningful to trading partners such that the recipient 
knows it can safely ignore anything received beyond the subset and 
the sender knows that restrict everything to within the subset and 
both consider themselves "conforming" to the use of the subset.

And (2) I'm not convinced the W3C Schema features of extension and 
redefine successfully describe the constraints ... I believe they 
have to be re-expressed from scratch in order to be successful ... I 
would be pleased to be shown by someone that I am wrong in this, but 
for the life of me I cannot get a processor to successfully interpret 
my attempts at using the schema language to effect the desired results.

>There is also the mention of "more granular,
>tighter subsets and a schema extension for such definitions" - knowing
>the issues folks have with W3C Schema, what is so lacking about W3C
>Schema (a ratified standard for 5 years now) that warrants potentially
>reinventing the wheel here? (continued below - breaking for
>readability:)

Again, we are not trying to reinvent the wheel ... we are merely 
cataloguing a subset of information items from a sacrosanct schema 
expression as a documentary artefact for use by implementers.

We are not trying to impose a new set of schemas ... that would be 
inappropriate from the perspective of UBL interchange ... *all* UBL 
messages can be interchanged, the subset merely defines what portion 
of those instances are meaningful in a given scenario.

>[JMC] If all one really needs to do is restrict data types using
>constraining facets, and add additional elements not currently
>supported, this can be done with W3C Schema. What am I missing here?

I guess *I'm* the one missing things here ... if I found it necessary 
(behind the scenes, not for interchange) to create a W3C Schema using 
redefine (there are no hooks for substitution), I cannot achieve the 
desired results using "ratified standard for 5 years now W3C Schema" 
... can you?  Can anyone show me how it would be done?  I've learned 
that MSV is non-conformant in this area and Xerces (considered 
conformant) reports multiple type definition errors for the 
redefines.  Though I am not, personally, in need of a W3C Schema 
artefact matching the SBS subset, I do not believe one can be created 
by using the standardized facilities and the sacrosanct UBL schema 
expressions.  I believe it has to be created independently and 
without use of redefine, thus creating a whole new set of schemas, 
which we most assuredly are not empowered to do since we are not 
changing the definition of UBL.

But that is moot ... we are defining a catalogue of information items 
from a set defined by a given set of schemas, we are not defining a 
new class of documents for interchange by describing new schema constraints.

>What is the benefit of using SBS over such an approach? Please educate
>me, as I want to learn.:)

And I want everyone to understand why the SBS exists "over such an 
approach":  BECAUSE IT DOES SOMETHING DIFFERENT!

The SBS does not attempt to describe constraints on a document used 
for interchange.  The UBL specification defines the W3C Schema 
constraints on a document for interchange and the SBS DOESN'T CHANGE 
THAT (NOR SHOULD IT).  The SBS merely documents which information 
items in the instances described by the normative schemas are to be 
considered meaningful between trading partners in a given scenario 
... in this case, the scenario of small business interests.

If people want to take the SBS description and synthesize for their 
own behind-the-scenes implementation issues any set of constraints 
(including W3C Schema, or RELAX-NG Schema, or whatever), they are 
welcome to do so PROVIDED THEY DON'T CONSTRAIN THE INTERCHANGE OF UBL 
INSTANCES by improperly rejecting a valid UBL instance BECAUSE THE 
SBS DOESN'T CHANGE THE DEFINITION OF A VALID UBL INSTANCE.

Sorry for the shouting ... I just wanted to make sure everyone can hear. :{)}

I thought this had been said before ... yet everyone seems fixated on 
W3C Schema expressions when we are not trying to change or to define 
any W3C Schema expressions, nor should we as that is not an expressed 
or required objective or deliverable or artefact of the SBS to 
achieve the goal of describing a catalogue of information items.

I hope this helps.

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

--
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
Also for XSLT/XSL-FO training:    Copenhagen,Denmark 2006-05-08/11
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