[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]