Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 2009-01-30 08:32 -0500, Costello, Roger L. wrote: >3. "Business-process-specific data versus >business-process-independent data" is a false distinction. There is >only kind of data: data for some purpose or purposes, and there is >only one kind of XML vocabulary: vocabulary that supports a purpose >or purposes. I would soften that a bit. What the information in a document means is up to the recipient. Hopefully he is understanding the information in the way the sender intended, but he isn't obliged to stick to that understanding. A recipient could choose their own document constraints (i.e. schema) and their own stylesheet or application to do anything they want with the information captured using an XML vocabulary and interpret it any way they wish. >6. Distinguish between the XML vocabulary you create versus the XML >vocabulary that is actually used in practice: when creating the XML >vocabulary, identify the optional markup (data) as described above. >Recognize, however, that the XML vocabulary may be used in >unforeseen contexts that require markup (data) above and beyond the >provided by your XML vocabulary. Design your XML vocabulary to >support these unforeseen use cases. One approach is illustrated in figure 21 on page 33 of the draft UBL Customization Guidelines: http://docs.oasis-open.org/ubl/guidelines/UBL-Customization1.0prd01.pdf This shows a processing model with two possible steps for schema validation, followed by a separate step for value validation (for code lists, identifiers and other business rule values). Focusing on the two steps for schema validation, a receiver may have created a "UBL Customization" comprising a subset of the very large UBL vocabulary. This subset has only those parts of UBL they are interested in, and for which they have programmed in their application. Their application may even be constrained to accept only the subset of UBL (perhaps they have turned on validation in JAXB and an instance is only bound to Java objects if the instance is valid; thus in order to inspect anything found in the instance it can only have what is expected). A document arrives at the system and the first schema validation may or may not succeed. If it does succeed, the process continues with value validation. If the first pass does not succeed, a transformation removes from the instance all unexpected constructs by only allowing expected constructs through an identity transformation. This transformed instance is then validated with the same schema as used in the first pass. If the second pass does not succeed, there is no point in continuing. If the second pass does succeed, the process continues with value validation. So there are two paths that will take content in to an application, and the pre-validation ensures the instance will be acceptable to an application that uses validation in its data bindings. The UBL TC suggests instances utilize available elements declaring the customization and subset to which they conform so that applications, when they do get around to inspecting the content, can look at these values to make a business decision regarding proceeding. These two paths then bring the instance to the application and the application can inspect the declared customization information against the expected customization information. There are four cases: No errors on the first pass and the customization is as expected: - processing continues and business is accomplished An error on the first pass and the customization is as expected: - the sender included unexpected information not defined by the customization - what is in hand is all that is needed, and according to the rules of the customization, anything removed wasn't important - probably acceptable to do business, unless the community dictates that unexpected content violates the rules of sending instances No errors on the first pass and the customization is not as expected: - this is a foreign instance but there is enough information with which to do business and nothing was taken away from the original - may want to flag for out-of-band exception handling, but probably acceptable since nothing was removed - business rules might require rejection if the instance is not marked for the customization An error on the first pass and the customization is not as expected: - this is a foreign instance and some information has been removed - something had to be removed to be processed - not knowing the rules of the customization, what was removed might have been important - may want to flag for out-of-band exception handling as one cannot be sure the original information wasn't somehow important - business rules might require rejection if the instance is not marked for the customization Again, this is all done as a prelude to the application running in order to (1) pre-validate the instance as acceptable, and (2) massage the instance in order for a validating data binding to pass the information to the application. We've been editing the document and diagrams based on feedback and our face-to-face plenary last week, and a new edition is expected soon. Note that the UBL vocabulary is designed to be both restricted and extended (as described in more detail in that document). I hope this is considered helpful. . . . . . . . . . . . . . Ken -- Upcoming hands-on XSLT, UBL & code list hands-on training classes: Brussels, BE 2009-03; Prague, CZ 2009-03, http://www.xmlprague.cz Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman@C... Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/x/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
