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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2007-02-10 12:33 -0700, David RR Webber \(XML\) wrote:
>Ken,
>
>I spotted these statements in the email discussions - that were grouped
>together (see below).

I'm not sure why you addressed me with this, David, as each and every 
one of these comments you cite are from Tim, not from me.  I focused 
on interchange of information and the conformance of the document 
model, *which is what started this discussion*.  Your points are 
disingenuous to the thread I started.

>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

I'll let Tim talk to your points, David, if he wishes but I 
personally will stay focused on this discussion about a 
tool/technology "providing 100% compatibility with the original UBL 
schemas" ... sorry, all along I've been talking about the interface 
between two applications according to a published specification and 
the normative component of that specification is a set of W3C schemas.

I don't care what CAM may or may not be able to do, and I don't know 
what CAM does or doesn't do, as successful interchange and the 
challenges you raise are all premised on the information being 
identified by being properly labeled using a published XML vocabulary 
that everyone recognizes.  Even a CSV file can have data errors and 
that's the responsibility of other layers and of tools to determine 
on top of basic interchange using CSV.

I didn't bring up that discussion you cite.  I brought up my issues 
against the stated notion that somehow an interchange UBL XML 
document that doesn't validate against the published XSD schemas 
because of stripping namespaces at the convenience of a tool or a 
technology can still be called "UBL".  Perhaps the tool is doing so 
because it is insufficient to the task and cannot handle namespaces 
or it is incorrectly working with namespace prefixes or default 
namespaces and not properly with namespace URI strings.

While any technology may be interesting to some, if it cannot handle 
a namespace-qualified XML document as specified by the W3C, then it 
isn't a fully XML-based tool.  If it cannot take an untouched XML 
document with arbitrary declarations of namespaces and the 
redefinitions of the default namespace all according to the XML 
specification, then it isn't a fully XML-based tool.  There are tools 
out there that act this way because they aren't implemented to the 
full specification of XML and namespaces for whatever reason.  Back 
in the SGML days there were tools that didn't implement all of SGML 
and users were told to use a simpler version and simple translation 
and somehow "it is all okay".  It is not okay for those people who 
wished to use the SGML features that were not supported.  As I said 
before, this is a common refrain and we are hearing it again from 
vendors of XML-based tools that do not handle what is possible in 
XML, and I felt compelled to bring this up because of new users of 
XML that have their eye on UBL.

Consider that the popular XSLT stylesheet processors have no problems 
with the proper arbitrary use of namespace URI strings, prefixes and 
default namespaces, so that means it isn't impossible to implement a 
fully-XML-based technology.

And it was Steve's example and comment that illustrates this premise 
I've heard from some vendors who have been pushing in the markup 
world that for some reason *just to be able to use a convenient tool 
that doesn't properly support XML* that the true XML document needs 
to be massaged for the tool (not for the user):

At 2007-02-09 09:11 -0700, stephen.green@systml.co.uk wrote:
>After making a schema as previously mentioned with zero namespaces
>(or at most one) and just one schema file I went on to
>customise the Catalogue proper UBL schema files too.
>...
>It does work so far
>though and a simple transformation both to and from UBL proper
>instances is made possible while allowing validation against a
>necessarily simpler schema. Reiterating:- that's a schema with no
>more than one namespace and no more than one module/physical file.

"necessarily" simpler?  Necessarily to what?  A tool?  Create brand 
new schema expressions of already-published schemas just to "make it 
simpler"?  It is a disservice to users to put the burden of 
translation on them if the tool they are using can't handle the UBL 
instances they receive or need to send.

At 2007-02-10 12:33 -0700, David RR Webber \(XML\) wrote:
>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.

And you are using this "simpler" term too and *that's* where I have a 
problem, David.  That is why I started this thread.  It is 
irresponsible and misleading to a community of new users of XML to 
somehow imply that if they are using a "simpler" markup version of a 
UBL document that it is a UBL document.

The existence of a "simple" transformation to and from schema-valid 
UBL and a "simplified" format is irrelevant and misguiding to new 
users who are being told "this is okay, it is still UBL" ... it isn't 
UBL and it cannot be used for interchange.

The labels of UBL (which are a combination of namespace URI and local 
name, not prefix and full name) are well-defined for interchange 
purposes and, therefore, should not be changed.

All I'm saying is do what you want to do behind the scenes, and I 
don't care what tools you use, just don't expose as UBL something 
that isn't UBL.  Don't publish an XML instance using the UBL local 
names and washed of the proper UBL namespaces and call it "UBL" 
because it isn't.  That is what Stephen was doing and that was why I 
was trying to help the UBL Dev community by taking from my time to comment.

My comments are unrelated to Tim's comments regarding compatibility 
and the design of custom business objects based on UBL business 
objects ... I'm focused on improperly purporting a UBL-like instance 
without namespaces as being UBL.

I'll let Tim respond to your comments, David ... I'll stay focused on 
the issues that I started.

. . . . . . . . . . . . Ken

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal