OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Simple working demonstration of NVDL - ISO/IEC 19757-4

At 2006-02-28 16:35 -0800, jon.bosak@sun.com wrote:
>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:


   NVDL Editorial comments to be incorporated before publication:


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:


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">
     <Description>747 Repair Kit</Description>
     <Description>DC3 Repair Kit</Description>

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


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


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


***** 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"
     <Description>747 Repair Kit</Description>
         <a:Description>Starboard wing</a:Description>
         <a:Description>Port wing</a:Description>
     <Description>DC3 Repair Kit</Description>
         <a:Description>Rubber band</a:Description>

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


***** 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">
             <!--break out line items for aerospace use-->
             <namespace ns="urn:x-aerospace:ubl:lineitem">
                <validate schema="aeroline.rng">

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]