ubl — archive

[Ken Holman]

With Jay's permission I am posting a reply written yesterday to an assessment he contributed regarding the paper being discussed next week. I just now see Steve has also posted, and I will get to that as soon as possible, though I am on holiday right now and this will have to wait (hopefully not long). I hope that the TC finds Jay's observations below and my responses useful. . . . . . . . . . . . . . Ken At 2006-07-31 16:10 +0100, Jay Cousins wrote: >Dear Tim & Ken & all, > >As Tim asked a while back (see thread below), >some review thoughts on Ken's UBL Customization >document - >http://www.oasis-open.org/committees/download.php/18849/gkholman-ubl-modeling-0.4.zip. > >I looked at this a while ago and have finally >found the time to write up my responses/thoughts >to this document as I read it. I wish that I had done this earlier. Any response is welcome, Jay ... I'm sorry that I haven't been able to make the time to respond. >Notes by section heading and paragraph >number. Many comments, mainly minor in >nature. My main objection was the notion of >serendipity which is a word I really wasn't >expecting to see in this context. I hope I have >not misunderstood what you mean by it, but I found it very confusing. You are not the only one, yet from my own perspective I cannot think of a better word to use. The connotation I'm trying to convey is that the system design supports two trading partners in a brand new trading relationship are able to immediately utilize, without changes, their pre-existing UBL implementations configured for other contexts. The WordNet definition of "serendipitous" as "lucky in making unexpected and fortunate discoveries" ... so as to indicate that two existing users of UBL in different contexts are "making unexpected and fortunate discoveries" in being able to forge an instant relationship without having to make changes. Whether this term ends up in official UBL documentation is not important to me, but it is working well for me so far in my trial runs of my UBL training class. >All in all, a very coherent work & I look forwrd >to reading the next version in due course. I suspect the next version will be a committee document rather than a personal contribution. >Really 4 groupings of comments - serendipity, XPath files, xsd, subset. > >Hope these comments are useful and not outdated >by a gkholman-ubl-modeling-0.5 already!! Thanks again, Jay, I very much appreciate the time taken to review this. >(Please excuse typos - I am using an hp in place >of my usual toshiba laptop today and the >keyboard is smaller and a little different...) :{)} >Best regards, > >Jay > >(Ken - yes, I met you at XML One in 2000 when I >first joined RivCom; Daniel Rivers-Moore introduced me to you.) I look forward to the next time! >COMMENTS: >Section 3.1 Read-only UBL XSD schemata. >2nd para. Propose to clarify how this applies to >compatible rather than conformant >customisations. The UBL 1.0 customization >document distinguishes between conformant and compatible extensions. Do you mean the document: http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/cm/wd-cmsc-cmguidelines-1.0-beta.html I don't see there a distinction between "compatible" and "conformant", though I do note that the definition of "compatible" seems predicated on XSD derivation techniques. I discounted the approaches presented historically for XSD schema derivation because of the research done by Stephen and Fraser into the limitations of the W3C Schema mechanisms available. I don't fully understand the limitations, I just know that I, too, was not able to get the mechanisms to work as required for the project. >Section 3.3 The "Serendipity Factor". >1st para. Sorry, but I and all I discussed this >with didn't like/accept the concept of >'serendipity' in an e-commerce exchange governed >by a TPA. I see where you are going here but, >to be frank, I'd drop the word serendipity and >find another word to describe this embracing scenario. So noted. I'm sure the committee will agree with this as you are not the only to comment in this regard. A specific comment I've heard is the term conveys a sense of "my system was able to be used without my authorization", which was never intended. Perhaps this is a sense that has also given you discomfort with the term. >2nd para. Given the optionality prevalent to >UBL I found the second sentence here confusing. Noted. Here I'm trying to convey that a particular deployment may choose to make an optional construct mandatory ... which it certainly is allowed to do. Such an implementation, however, could not be party to a serendipitous exchange (that is, one between implementations configured for other contexts) because the sender could very well have not used the optional construct and the document is rejected because the deployment is expecting it to be mandatory. >3rd para. Not sure what is meant by 'incoming >instances need to be massaged' - please clarify. See the discussion in section 8.2.2 and figure 4 for the detail. >4th para. For me this contradicts the notion of >serendipity. I think if yoy dropped the word >serendipity this para virtually provides the essence of this section. It was my goal for this summary paragraph to clarify my use of the word "serendipity" based on comments received from earlier drafts. I've apparently failed to do so! :{)} >Section 3.3.1 Example scenario 1 Cross-governmental boundaries >2nd para.Need to define 'core', please. Terminology is an issue and in the group process the committee needs to establish common words. By "core" I mean "the normative bits standardized by the committee", unchanged, upon which subsets are based. I used it first in section 3.2, though I didn't define it there. An alternate term I'm considering is "baseline", as if to imply you are building on top of it. >3rd para. So serendipity is conformance to the >UBL model *without* extensions - yes? Yes. >- which makes perfect sense - but for this a UBL >compliant system would need to implement the >entire UBL model, including all optional content, no? I don't think so ... For example the absolute minimum invoice instance has only the following information items: /in:Invoice/ /in:Invoice/cbc:ID /in:Invoice/cbc:IssueDate /in:Invoice/cac:AccountingSupplierParty/ /in:Invoice/cac:AccountingCustomerParty/ /in:Invoice/cac:LegalTotal/ /in:Invoice/cac:LegalTotal/cbc:PayableAmount /in:Invoice/cac:InvoiceLine/ /in:Invoice/cac:InvoiceLine/cbc:ID /in:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount /in:Invoice/cac:InvoiceLine/cac:Item/ >If not how can serendipity apply? It's not clear >to me if the minimum requirements are stated or >not. I assume that 'minimum requirements' are >support for the whole UBL model. Personally, I think that 'minimum requirements' is support for only the mandatory elements. If an invoice processing system supported only the absolute minimum elements above, and the invoice gets paid without need for *any* optional elements, then payee gets his money from the payer without either having to change their systems. Obviously this would probably be an optional mode of operation, as having a number of the optional items would often be required to meet business needs by the paying organization. But by encouraging deployments to have such a mode of operation, then two brand new trading partners could use their existing implementations of UBL with an agreement to work, perhaps just one-off or for a temporary period of time, in this "minimal mode" until such time as their systems can be modified to meet more business requirements. Without propagating this concept of being able to work, even just optionally, in such a minimum mode of operation, I'm worried that UBL deployments will create obstacles for new trading partners to either quickly or just temporarily do business by mandating changes to existing implementations. >However, Section 5 of the document shows that a >system that does support the UBL model is >'UBL-open'. So I think the meaning here is that >serendipity requires a UBL-open system? Can you make this explicit? Yes, my thought was that a UBL-open system is one that supports the absolute minimum in a mode of operation that suspends business rules that would otherwise cause the instance to be rejected. Whereas a UBL-conformant system is one where the business rules are not suspended and a UBL-conformant instance not meeting the rules is rejected, but one that does meet the rules is accepted. >4th, 5th para. Good example of my problem with >a serendipitious exchange - it has failed, no? A >trading partner has been passed a file that >doesn't conform to the file types they accept. "Doesn't conform" to the business rules or UBL optional elements that have been made mandatory are not present. >If I try and read past the resident geek hacking >the invoice (which is giving me nightmares), :{)} But I'm not ruling it out! >the use case steps/workflow here is that the >file arrives, the system determines that the >file is not valid, the file is pre-processed to >augment the file so that it corresponds to an >accedpted file type, the file is re-submitted to >the invoice system, the system determines that >the system is of an acceptable file type and >then accepts it. Putting it differently, the >file is validated against structural and business rules upon receipt. Ah ... not my intention ... these modifications and actions I'm citing are being done by the *sender* not the *receiver* ... so the receiver has rejected the instance and so the sender goes through all of the machinations necessary to meet the requirements of the receiver. The geek, therefore, works for the sender. And the sender eventually modifies their system to accommodate the receiver, using these fallback methodologies until such time as their system is changed. >Final outcome is the system is then upgraded to >receive the new file type, which has >implicitly,therefore, been added to the list of >accepted file types - which happens in the 6th para. By the *sender* not by the receiver ... in this example the receiver implementation is rigid so the sender has to make the accommodations. >Section 4. XPath files. > >1st para - typo - missing 'in' before 'XML instances'? Noted. >Section 4.3 XPath files for tests of presence and coverage. > >2nd para. I can't think of another scheme for >implementing 'exhaustive proof of conformance >and compatibility' offhand either. Quite like this. Stephen and I are finding that XPath files are becoming very useful. Their nascence was for my stylesheet development (and I still use them for that). In preparation for the next release of XPath files, we are trying to consider what new features are needed in the XPath file model. In essence, the XPath file is an XML expression of the distillation of the XSD files. We have type information, cardinality, and have made the hierarchy explicit. Can you think of anything more we can put into an XPath file that developers might want out of the XSD file? >Seems similar approach to Schematron testing for >rules. I note that you refer to Schematron in >Section 8.1.2 Subset supplementatl validation artefact preparation Yes, Schematron is integral to the value validation that incorporates subset needs and trading partner needs. >Section 6.1 Unable to declare derivatives of the extension point. > >Can't be much help here. I find this section >difficult to read, sorry, so think I am not >understanding the precise problem. No apology necessary. I'm trying to put into prose an issue that I usually have to wave my arms to describe. >Given the optionality of the UBL schema ##any >giving problems doesn't surprise me. Why ##any >and not ##other - to allow extensions from the UBL namespace, presumably? No, because I cannot do in XSD what I can in RELAX-NG: a "multiple-namespace other". There are many namespaces in UBL, and XSD "##other" only can exclude the one target namespace. For example, in RELAX-NG I can say: element * - ( cac:* | cbc:* | udt:* | sdt:* ) which would allow any element except elements in any of the UBL namespaces. There is no way in XSD to say "other than the following set of namespaces". Specifically to your anticipated scenario, I hope that no-one defining extensions uses a UBL construct as the apex element of their sub-tree. >I would see problems through the use of xs:any >##any leading to a non-deterministic model but >you should be able to avoid that with xs:any >##other - which I am sure you don't do for a >good reason. The xsd problems here include ##any >and type extension/restriction limitations as >you say. The way I have approached this kind of >problem in the past is through refactoring the >type hierarchy, greater use of xs:groups, and >thinking along DTD lines - wrapper elements for >extension points, parameter entities, >include/ignore - to try and think/find a way >around it. If you sent me a schema fragment >illustrating the problem then I would likely understand the problem... I hope the explanation above illustrates why I feel compelled to use ##any. >Section 6.2 Unable to elide optional elements through derivation. > >I think I misunderstand the problem. I presume >by elide is meant remove by xs:restriction. From the *middle* of an element's definition. >If I create a base type with a required and an >optional element, say, I can restrict the base >type to remove the optional element. What I >cannot do is restrict it to remove the required >element. So what is the problem? The only >problem I can think of to stop me doing this is >restricting across different namespace schema, >in which case you couldn't do it. Is this a >namespace issue? Do the schem have same or different namespace? Perhaps I misunderstand the restrictions of restriction. In XSD can I import a fragment with (the shorthand) content model of "a, b?, c+, d*" and somehow restrict it to be "a,c" using XSD restriction? >Section 7.4 Subset UBL conformance > >3rd para. typo 'the its business rules' > >5th para. typo 'the an absence' Noted. >Section 8.1.2 Subset supplemental validation artefact preparation. > >3rd para. Up to here reading Section 8 Subset >deployment recommendations I have had UBL 1.0 >conformant customisation and subsets in mind - >now there is mention of extensions. I think >more is needed in the document on extensions to clarify how they are handled. "Handled" in what respect? Because of the "##any" document model, an instance implementing an extension is still a "conformant UBL instance" because it doesn't violate any XSD constraints. And since extensions are optional, a system accepting the presence of only mandatory information items will just ignore extensions. >For example, on someone taking the UBL model and >(having or having not created a subset to meet >their needs first) extended it to add vertical >industry specific extensions, as in my usage case. Right ... your extensions go in your namespace under the extension point. When your system needs to have access to these extensions, you can find them. Business rules can enforce the presence of extension information items with the presence of baseline information items. In a "lax" mode of operation of your software, you can choose to accept only the baseline information items in the absence of your extensions. >Also, the conformant/compatible distinction of >UBL 1.0 customization seems to not be mentioned any more in these guidelines? I acknowledge that and will review them once again for applicability. >Section 8.2.2 Application handling of an arbitrary UBL instance input. > >the Note. Possibly relevant comment or not - thinking of JDF, "JDF"? >you would configure your system to interrogate >the schema version attribute and then apply the correct schema to it. There are a number of element information items for this task: