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

["Stephen Green" <stephen_green@seventhproject.co.uk>]

Ken

I agree
- that was easier to write than I expect your e-mail was :-)

Thanks for agonizing over the words.

My question is now -

You expound on 'constraints' and explain that XSD needn't be used
to express them,

but:-

If XSD were to be used;

Is there a (standard or accepted) way to say in or with the XSD
what *kind of constraint* we are using? (I refer to the kinds of constraint
at the end of your message)

If not, can we invent one?

Thanks again and thanks to Sylvia for bring the matter 'to the table'

All the best

Steve

P.S.  I guess 'context' gives us a way to say the *reason* for the
constraint(s)


----- Original Message -----
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
To: <ubl-dev@lists.oasis-open.org>
Sent: Tuesday, June 22, 2004 8:26 PM
Subject: RE: [ubl-dev] Creating a new document... where to start?


> 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
>
>