Re: [ubl-dev] UBL- just how reliable are XSD based syntax checks?

[Paul Thorpe <thorpe@oss.com>]

Hi David,

Use of solid XML Schema tools (such as the OSS XSD/C Tools) will trap
things like invalid XML characters, or null pointers in a C structure
representing the XML document you would like to serialize.  A good tool
will gracefully pass this kind of information back to the application
rather than allowing invalid documents parsed/serialized.

Of course there is a degree of flexibility in how strict you would like
this checking to be.  Some tools (including the OSS XSD/C Tools) allow you
to specify relaxed checking or strict checking.

----------------------------------------------------------------------------
Paul E. Thorpe                                 Toll Free    : 1-888-OSS-ASN1
OSS Nokalva                                    International: 1-732-302-0750
Email: thorpe@oss.com                          Tech Support : 1-732-302-9669
http://www.oss.com                             Fax          : 1-732-302-0023

On Sat, 10 Feb 2007, David RR Webber (XML) wrote:

> 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.)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>