RE: [ubl-dev] Creating a new document... where to start?

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

Thank you, Sylvia, for your contribution.

At 2004-06-22 08:37 -0700, Sylvia Webb wrote:
>I agree with your assessment about using different namespaces.

I'm not sure we are yet singing from the same song sheet ... but we are if 
I've just missed something in your short description.

*If* you are proposing your UBL-PurchaseOrder-Example.xml as a *parallel* 
set of validation requirements, then yes, sure, you can have any set of 
constraints you wish that can be constraints to the published UBL schemas 
provided the published UBL schemas are also used to validate instances that 
you validate in parallel with your private schema.  End of discussion, I 
think ... though I cannot take the time to look at the actual restrictions 
you have expressed ... I don't need to because when I write my software 
module to recognize the information in your instances I'll be using the 
published schemas in my work regardless of whatever schemas you use for 
your work.

*If* however you are proposing that your private schema is sufficient to 
the task of validating a purchase order document, then there is a 
disconnect, and I'll write the rest of my note assuming that you are 
claiming your customized purchase order is sufficient in and of itself only.

>As an
>example, I have created a simple subset of the UBL PO.  This subset simply
>defines what I want to send to a trading partner. I call it a Profile
>schema.

I see that your supplied XML instance does validate against your supplied 
Profile schema.

>It contains no changes to the basic UBL Purchase Order.

To test your assertion that it has no changes to the basic UBL Purchase 
Order, I tried validating your XML document against the published UBL 
document type:

===8<---
validating t:\UBL-PurchaseOrder-Example.xml
Error at line:32, column:63 of file:///t:/UBL-PurchaseOrder-Example.xml
   attribute "amountCurrencyID" has a bad value: the value is not a member 
of the
  enumeration.

Error at line:67, column:49 of file:///t:/UBL-PurchaseOrder-Example.xml
   attribute "amountCurrencyID" has a bad value: the value is not a member 
of the
  enumeration.

the document is NOT valid.
===8<---

It turns out that the attribute value in the instance is your placebo 
"XXXXXXXX" which is not allowed by UBL.  But it is being allowed by your 
schema.

That would mean that a customer entering "UDS" instead of "USD" would pass 
your schema but not the UBL schema.

>It is a
>definition of what my company needs.

This may be true, but if this is exclusively what your company needs then 
your company's applications implement different semantics than those 
supported by the published UBL schemas.  How do I know this?  Because the 
published UBL schemas are the normative expressions of the syntax agreed to 
by the UBL committee, as documented in the spreadsheets and other 
supporting documentation.

The assertion that your XML document meets the documented semantics by the 
UBL committee is your use of the UBL URI.

I think you are violating the assertion with foreign syntax (the code list 
values) not expected by the published documentation (as realized in XSD 
syntax) and the proof is that your instances don't validate against the 
published schemas.  That is, again, *if* you are claiming it to be exclusive.

>I am not aware of any UBL rules that
>require that a new namespace be used in such circumstances.

I wouldn't look for a UBL rule, I'd look for the principle that namespaces 
represent published vocabularies.

>If I am wrong,
>please point me to the document and section that states this requirement.

Here I quote the Motivation and Summary section of "Namespaces in XML 1.1" 
at http://www.w3.org/TR/2004/REC-xml-names11-20040204/#sec-intro for reference:

===8<---
We envision applications of Extensible Markup Language (XML) where a single 
XML document may contain elements and attributes (here referred to as a 
"markup vocabulary") that are defined for and used by multiple software 
modules. One motivation for this is modularity: if such a markup vocabulary 
exists which is well-understood and for which there is useful software 
available, it is better to re-use this markup rather than re-invent it.

Such documents, containing multiple markup vocabularies, pose problems of 
recognition and collision. Software modules need to be able to recognize 
the elements and attributes which they are designed to process, even in the 
face of "collisions" occurring when markup intended for some other software 
package uses the same element name or attribute name.

These considerations require that document constructs should have names 
constructed so as to avoid clashes between names from different markup 
vocabularies. This specification describes a mechanism, XML namespaces, 
which accomplishes this by assigning expanded names to elements and 
attributes.
===8<---

Note the phrases "elements and attributes that are defined for and used 
by..." (which is the UBL vocabulary) and "recognize the elements and 
attributes which they are designed to process" (as identified by the 
namespace URI) and "to avoid clashes between names from different markup 
vocabularies".

So, your use of the label:

   {urn:oasis:names:tc:ubl:CommonBasicComponents:1:0}LineExtensionTotalAmount

that allows values beyond the values to be recognized by software modules 
that are designed to process the instances (as described in the namespaces 
motivation) is not sufficient because allowing values not recognized by the 
published schemas qualifies as a "clash" of names for elements and 
attributes.  But, when supplemented with a parallel analysis against the 
published schemas before judging validity, then we are back to the 
published schemas being the normative check that the values entered are 
okay, and what you do with your own schemas is irrelevant because the whole 
world will (hopefully) be writing software against the original semantics 
and will, therefore, be using the published schemas to validate the inputs 
are acceptable.

So, a lot said, most of which is inapplicable if your proposal is in 
parallel with the published schemas, or which is my argument against 
purporting your schema as a "normative UBL schema" in and of itself.

It comes down to what you claim about your custom schema, you would claim 
it is either a standalone UBL subset (which it isn't) or a supplemental set 
of parallel constraints on UBL instances (which it is).

I've not tried to put this into words before, but I think people put too 
much into what a schema expression represents versus how a schema 
expression is used.  I believe a schema expression is merely a set of 
constraints, and if I claim that they are a parallel set of constraints to 
a normative set of constraints, then they can validly utilize any existing 
namespace URI.  I'm not claiming my additional constraints exclusively 
represent the labels that trigger the semantics of the namespace URI, 
because they don't, I'm only claiming that an instance is further 
constrained by my constraints in addition to the normative constraints 
represented by published schemas.

Perhaps if I used the phrases "normative constraints", "derived 
constraints" and "supplemental constraints" ... UBL publishes normative 
constraints, while the small business profile could do one of two things:

  (1) - publish a set of derived constraints suitable for use in isolation
        because the derivation process categorically (by design of the
        constraint expression language) restricts the new constraints to
        a subset of old constraints
      - note to engage this categorically successful derivation it is
        necessary that the derived constraints import and redefine the
        normative constraints "on the fly" as the validation software will
        ensure that the derivation techniques are not violated
      - from what I've seen, however, this is a labourious task due to the
        inability to override only selected facets of schema validation

  (2) - publish a set of supplemental constraints never to be used in
        isolation but expressed as a convenience for further constraining
        what is checked by the normative constraints
      - this requires two passes for total validation (note that DSDL is
        standardizing a validation choreography and orchestration language
        for doing just this with a single expression pointing to parallel
        constraint expressions)
      - one is not obliged to use W3C schema constraint expressions and
        can choose a constraint expression language that may fulfill their
        requirements more precisely, thus unburdening their applications
        from having to make-up lost ground not addressed (hence the
        convenience)

I think I've got to find better words, but I hope I've conveyed what I wanted.

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


--
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
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 Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal