[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] UBL- just how reliable are XSD based syntax checks?
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]