UBL- just how reliable are XSD based syntax checks?

["David RR Webber \(XML\)" <david@drrw.info>]

Ken, 

I spotted these statements in the email discussions - that were grouped
together (see below). 

Now - let me postulate that it is entirely possible to create XML
documents - that while they may conform to the UBL schemas exactly -
will cause any UBL-based system to crash and fail if they attempt to
process them - with such errors as null pointer exceptions, character
exceptions, invalid data errors, namespace exceptions, SQL errors and
more - EVEN THOUGH the XML passed the XML parser schema check just
perfectly!  I speak from hard experience with XSD based validation of
XML content in production systems. 

This is just the nature of the beast that XML has become - because of
the ad hoc way "v1.0" of XML is still labelled as v1.0 - but in reality
we are on version 5 or 6 something and counting, with all the nuances
this entails. 

To overcome this - you should most definately be supplementing your
basic schema checks with specific content checks of the kind that CAM
enables AND contextual cross-field checks - again possible with actual
business rules.   

Conversely then we should note that where the on-the-wire-format in XML
may be simplified to permit easy processing - while at the same time -
via a simple transform mechanism like CAM - will provide 100%
compatiblity with the original UBL schemas - when that check is
introduced into the process as a conformance check. 

The statements from the email I referenced above I feel need some
clarifications - see my notes below: 

<snip> 
This simple fact enables software developers 
>to proceed with some comfort that not only will their software have 
>clear specifications but that correctness of their solutions can be verified. 

[[[ Since an XSD schema merely informs of all possible permutation that
may be received - the only really strong claim here maybe that the
structure and layout of the content is conformant to the UBL schemas.
Much is made optional that in context is in reality required, or should
occur in a specific pattern or permutation. I would not want to claim
therefore that anything was "correct" in any business sense - other
than just purely structural. 
]]] 

>
>I take compatibility to mean consistent or in keeping with the 
>principles of something. It has a softer emphasis and suggests 
>common agreement on basic principles. I mean it to suggest a shared 
>heritage but without necessarily guaranteeing conformance.
> 

[[[ Obviously compatibility has to have some measure with it - such as
100% compatible.  Or backward compatiblity is assured.  Conformance is
usually associated with a specific version - and test mechanism - in
this UBL case XSD.  Conformance is tied to some goal - such as XSD
provides structural layout conformance.  You really need BOTH of these
things in some measure...]]] 

>It is reasonable to expect and encourage implementations that cannot 
>or do not require conformance to develop compatible customizations 
>where feasible. 

[[[ This is indeed so.  But what of where conformance can be achieved by
simply applying a transformation that produces a layout and structure
that is UBL conformant? ]]] 

>
>So all documents conforming to the UBL standard will be UBL 
>compatible but not necessarily all UBL compatible documents conform 
>to the UBL standard. 

[[[ I think I understand what this means - but I would not want to
explain it too much! 
     Most people - so long as their transactions are delivered and
processed - will  
     probably not lose too much sleep on any score! As I asserted
earlier - I'd wager that 
     UBL transactions that conform - may not actually process - so I'd
hate to be setting 
     too high expectations. ]]]
</snip> 

So - I think it reasonable to hold out conformance to the XSD as being a
useful means to establish membership in the UBL family - but for
operational systems between partners - they will need to supplement
those checks.  By exposing these rules as standardized CAM templates -
we make it easier for partners to understand these additional
processing needs and details. 

Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)