[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [ubl] Simple working demonstration of NVDL - ISO/IEC 19757-4
I am 100% in agreement with all these points, from my point of view xsd:any is a hack made necessary by the reliance on XML Schema, that said I doubt that at this late stage we can scrap XML Schema usage. NVDL as a technology solves the namespace problem no doubt, there have been various ways to solve it, including NRL which NVDL has grown from. XSL-T can be used to solve the problem elegantly of extracting only UBL namespaced structures before processing, and being able to understand these namespace problems and dealing with them is what I would consider one of the ground laying principles of being a competent in XML processing. That said I am not sure how many developers would match my definition of competent, most of them seem to just want to run the document through their xml schema processor and if it says valid, go! Unless we define this as an official point of UBL interoperability, that an instance has an extensibility model like this, then I think we can expect interoperability to fail at points of actual implementations. Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] Sendt: 1. marts 2006 03:57 Til: jon.bosak@sun.com; ubl@lists.oasis-open.org Emne: [ubl] Simple working demonstration of NVDL - ISO/IEC 19757-4 At 2006-02-28 16:35 -0800, jon.bosak@sun.com wrote: >MINUTES OF PACIFIC UBL TC MEETING >00H30 - 02H30 UTC TUESDAY 28 FEBRUARY 2006 >... > GKH: The way to extend UBL is by allowing the arbitrary use > of non-UBL namespaces in UBL instances and applying NVDL, > the JTC1 Namespace-based Validation Dispatching Language. > This is Part 4 of ISO/IEC 19757, which is at FDIS and will > soon be an ISO/IEC standard; see dsdl.org. Will suggest > this to BR. > > JB: So we can stick in anything using the DSDL notion of > "valid"... > > GKH: No, when you extract the UBL [using NVDL], it's valid > UBL.... Like embedding SVG in XHTML. > > JB: Which was the whole intent of namespaces from the > beginning. This is what TimBL wanted in the first place! > I'm much more comfortable with this approach than with ANY. The project editor for NVDL is Mr. Makoto Murata and the project documents can be found as follows: NVDL FDIS sent to ITTF: http://www.jtc1sc34.org/repository/0694c.htm NVDL Editorial comments to be incorporated before publication: http://www.jtc1sc34.org/repository/0717.htm Since last night's meeting I've done some looking around and the state of implementation is not very good at this point, but that can be anticipated due to the incomplete development nature of the specification. Now that it is finalized we should be seeing more implementations before long. It is exciting to see what is being done. In the meantime, Makoto announced the "enovdl" implementation of NVDL he was aware of and I downloaded the Windows executable created by Makoto that he linked from: http://lists.w3.org/Archives/Public/public-schemata-users/2005Oct/0001.html Unfortunately, he states that it only works on Windows and due to a bug in Windows it will not work with XSD files. So, we will have to wait for another implementation to work samples with real UBL, but hopefully it won't be long. I tried real UBL just in case something was fixed in my version of Windows, but I was unable to get it to work. Meanwhile, here is a working demonstrative example of what I think we could do with UBL, but using RELAX-NG as the modeling language instead of W3C Schema XSD. But the principles are *identical*. Below is a transcript of a batch file in my Windows test environment, run in the "T:\test" directory and I'll annotate in between some of the lines starting with "*****" ***** We start with a UBL-compliant order instance (in this case greatly simplified) for some airplane repair kits. Note how the line item detail is very broad and doesn't give detail that might be useful to someone in the know: T:\test>rem An order without any extensions T:\test>type exubl.xml <?xml version="1.0" encoding="utf-8"?> <Order xmlns="urn:oasis:names:draft:ubl:schema:xsd:Order-2"> <OrderNumber>123</OrderNumber> <LineItem> <Description>747 Repair Kit</Description> <PriceAmount>1200000.53</PriceAmount> </LineItem> <LineItem> <Description>DC3 Repair Kit</Description> <PriceAmount>37.25</PriceAmount> </LineItem> <TotalAmount>1200037.78</TotalAmount> </Order> T:\test>rem ***** To prove that the instance conforms as is to a model, here is the RNC (RELAX-NG Compact Syntax) for the simple UBL order for this test (converted to RNG -RELAX-NG - for later use) and we will consider this a sacrosanct, read-only document model we are not allowed to change: T:\test>rem The order model (in RNC and RNG forms) T:\test>type exublorder.rnc default namespace = "urn:oasis:names:draft:ubl:schema:xsd:Order-2" start = element Order { element OrderNumber { text }, element LineItem { element Description { text }, element PriceAmount { text } }+, element TotalAmount { text } } T:\test>call trang -I rnc -O rng exublorder.rnc exublorder.rng T:\test>rem ***** Let's validate our example against our model to know that I haven't mistyped anything: T:\test>rem Validating the order without extensions T:\test>call jing exublorder.rng exubl.xml T:\test>rem ***** Okay, no errors reported, so now let's look at what detail we might have in a line item oriented around aerospace orders, a simple set of parts such that a single LineItemDetail can have any number of Part elements. Note how this is a model for a micro-vocabulary with the namespace "urn:x-aerospace:ubl:lineitem" so that anything we use in that namespace is disambiguated from anything we use in the UBL namespace (it wouldn't be up to UBL to declare this namespace, the aerospace UBL users would come up with their own namespace): T:\test>rem The document model for an aerospace line item T:\test>type aeroline.rnc default namespace = "urn:x-aerospace:ubl:lineitem" start = element LineItemDetail { element Part { element Description { text }, element Quantity { text }?, element Amount { text } }+ } T:\test>call trang -I rnc -O rng aeroline.rnc aeroline.rng T:\test>rem ***** We now have two models in RNG: the unmodified, sacrosanct, read-only UBL order model, and the aerospace line item detail model. Here is an augmented instance of our UBL order with embedded use of the aerospace line item detail micro-vocabulary using the aerospace namespace: T:\test>rem The aerospace order with extensions T:\test>type exaeroorder.xml <?xml version="1.0" encoding="utf-8"?> <Order xmlns="urn:oasis:names:draft:ubl:schema:xsd:Order-2" xmlns:a="urn:x-aerospace:ubl:lineitem"> <OrderNumber>123</OrderNumber> <LineItem> <Description>747 Repair Kit</Description> <a:LineItemDetail> <a:Part> <a:Description>Starboard wing</a:Description> <a:Amount>600000.00</a:Amount> </a:Part> <a:Part> <a:Description>Port wing</a:Description> <a:Amount>600000.00</a:Amount> </a:Part> <a:Part> <a:Description>Bolt</a:Description> <a:Quantity>2</a:Quantity> <a:Amount>.27</a:Amount> </a:Part> </a:LineItemDetail> <PriceAmount>1200000.54</PriceAmount> </LineItem> <LineItem> <Description>DC3 Repair Kit</Description> <a:LineItemDetail> <a:Part> <a:Description>Rubber band</a:Description> <a:Amount>37.25</a:Amount> </a:Part> </a:LineItemDetail> <PriceAmount>37.25</PriceAmount> </LineItem> <TotalAmount>1200037.79</TotalAmount> </Order> T:\test>rem ***** At this point, what if we tried to validate the augmented order with the UBL order model? We get errors of the unknown embedded elements: T:\test>rem Failed attempt to parse aerospace order with UBL order T:\test>call jing exublorder.rng exaeroorder.xml T:\test\exaeroorder.xml:7: error: unknown element "LineItemDetail" from namespace "urn:x-aerospace:ubl:lineitem" T:\test\exaeroorder.xml:26: error: unknown element "LineItemDetail" from namespace "urn:x-aerospace:ubl:lineitem" T:\test>rem ***** But, we can express in an NVDL map that content found in the UBL namespace is validated using the UBL vocabulary model, and the content found in the aerospace line item namespace is validated using the line item micro-vocabulary model: T:\test>rem NVDL mapping of namespaces to schemas T:\test>type aeroorder.nvdl <?xml version="1.0" encoding="utf-8"?> <rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0"> <!--outer document is UBL--> <namespace ns="urn:oasis:names:draft:ubl:schema:xsd:Order-2"> <validate schema="exublorder.rng"> <mode> <!--break out line items for aerospace use--> <namespace ns="urn:x-aerospace:ubl:lineitem"> <validate schema="aeroline.rng"> <mode> <anyNamespace> <attach/> </anyNamespace> </mode> </validate> </namespace> </mode> </validate> </namespace> </rules> T:\test>rem ***** Let's use this dispatching of validation tasks based on namespaces by using the enovdl implementation of NVDL: T:\test>rem Successful NVDL dispatched validation of namespaced-content T:\test>call nvdl aeroorder.nvdl exaeroorder.xml Schema parsing...done. Instance parsing and validating...done. This document is valid. ***** Bingo! End of validation ... we know the use of aerospace line item information in the instance is acceptable, and that the UBL information in the instance is acceptable. There is a *lot* more to NVDL, but that is the gist of my proposal for its use for UBL. Note that if we had to also guarantee that every UBL line item *had* an aerospace line item detail, then we could express that as an assertion in a Schematron script and validate its presence using that. Document Schema Definition Languages (DSDL) ISO/IEC 19757 http://dsdl.org is a multi-part standard with a number of different validation languages (note the plural in the name): Part 2 is RELAX-NG, a grammar-based validation language. Part 3 is Schematron, an assertion-based validation language. Part 4 is NVDL, a mapping language to map namespace vocabularies to document models There are many other parts. These are designed to work together to address different aspects of the validation process. Note that NVDL *does* work with W3C XML Schema (a type-based validation language), but bugs in Windows prevent the implementation above from working with XSD files, otherwise I would have used the bona-fide UBL Order model in the above. I see the basic premise as: - the UBL information in an order instance has to conform to the sacrosanct, read-only document models created by the UBL Technical Committee; - at the least, a user of augmented orders must fill in the UBL fields so that recipients who do not recognize the augmentations can ignore them because the fields they do recognize they know what to do with; - users who choose to recognize the embedded augmentations can do what they wish with them, just the act of having them doesn't "disturb" the UBL information in the instance. This is a different way than the traditional way of looking at document validation where you have to have the one model of everything in the instance, but it really isn't foreign. Consider that you have an XHTML document ... if you choose to embed an SVG image in the middle of the document, you still really do have an XHTML document just with something inside. Why burden the XHTML document model with knowledge of SVG details in order to do validation? With namespace-based validation dispatching, the detection of SVG in an XHTML document can trigger the validation of the SVG component with the SVG model, while making the SVG invisible to the validation of the wrapping XHTML from the XHTML model. So as trading partners we don't "validate an instance as valid UBL"; instead we "validate the UBL information in an instance as valid UBL", as well as checking whatever other information we might also have in our instance that is important to our exchange. I hope this helps. . . . . . . . . . . . . . Ken -- Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17 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/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]