Namespace URI string implications

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

Further to tonight's teleconference, I brought up a concern of a 
decision Paul Thorpe and I heard in Brussels that we didn't realize 
was in the works and that has critical deployment ramifications that 
I feel the committee should discuss.

But I gather from Jon's comments in the call, this is a 
long-hashed-out issue and I run the risk of angering a number of 
members by bringing this up.  But I don't believe I had been party to 
the discussion earlier as this was a surprise to me, so belatedly 
I'll bring up the issue that Paul raised and an issue that I've 
determined from documenting my proposed subsetting and extension methodologies.

I don't want to put words into Paul's mouth, so I'll invite him to 
comment himself, but I guess that perhaps this hadn't been widely 
known since it was news to him as well.

Paul and I believe that *any* change to the document models 
*requires* the namespace URI string to be different ... even for 
minor changes because a 2.1 document model will have more information 
items than a 2.0 instance ... keeping the namespace URI strings the 
same and embedding version information will have major deployment 
problems with respect to validation.

We cannot have the same namespace string identifying the vocabularies 
for UBL 2.0 and a modified UBL 2.1 for the following reasons 
(probably among others but these are show-stoppers), based on the 
premise that W3C validation associates the namespace URI string to 
the structures of the document through the targetNamespace= property 
in the document element of the schema ... thus, there is a strict 
association between what the string says and the document model, 
producing the following issues:

(1) Deployment of a heterogeneous system
  - there is no way we can shut down global UBL usage of a 2.0, 
deploy 2.1, and start the world up again
  - a system that has upgraded to 2.1 will forward what they consider 
to be a UBL valid instance, since it validates in their system 
against the published 2.1 schemas, to a 2.0 system, and the 2.0 
system will reject it for non-compliance to the UBL schemas they are 
using that are
  - I'm told there is a parallel with ASN.1 ... Paul has customers 
with networks of thousands of users of heterogeneous implementations 
of the ASN.1 equivalent of a document model and they must be uniquely 
identified for the high-speed algorithms in the interface chips to 
accurately accept and reject properly-formed ASN.1 messages

(2) The front-line interface to many programs is validation
  - one comment in Brussels was that the version information is to be 
found inside the instance
  - there are program interfaces to XML that "pre-compile" the W3C 
Schema expression into artefacts such as Java classes and C# data structures
  - I understand such interfaces are keyed on the namespace URI 
strings based on the targetNamespace= property ... perhaps someone 
can tell me otherwise, but if I compile a cac:Party into a C# data 
structure and the data stream arrives with a matching target 
namespace but more information items that my data structures can 
support, can someone tell me what the program does with the extra 
information items?
  - the premise of blind XML document interchange is that the 
receiver validates what the sender sends so that the receiver's 
program knows what the sender is sending is acceptable ... if we 
expect programs to go into an XML document and examine the version 
information item, an instance won't even get past the gatekeeper of 
W3C Schema Validation if a 2.1 instance is sent to a 2.0 
implementation because the 2.1 namespace is interpreted as having the 
2.0 document model and the presence of the 2.1 information items 
kills the data flow before the program even sees the instance

A possible mitigation as I write this is to use a 2.1 namespace URI 
string but us it *only on the elements that are new to version 2.1* 
and not on the document element.  But this will mean we must 
introduce a namespace-based exorcism step in the deployment of UBL 
applications where a "filter" step that is engaged after receipt of a 
message will preserve information items in the UBL namespaces that 
are supported by a given deployment, and elide the information items 
that are not supported.  Then, schema validation will proceed without 
"tripping" over the information items that are not expected, and it 
will be able to find the version information in the structure because 
the filtered structure will have passed validation.

But it means that we still need to introduce new namespace URI 
strings in order to distinguish the new information items of 2.1 from 
the old information items of 2.0.

Paul and I heard of the decision and when we tried to bring it up on 
the Friday there was insufficient time to talk about it before I and 
others had to leave for the airport.

If UBL members still believe that we can have one namespace URI 
string for two different document structure declarations, could you 
please help us understand how the two issues above are addressed.

Paul, could you please add your own spin on this?

I've written this very quickly in order to get the debate started ... 
I apologize if I've missed something obvious.  On the call it seemed 
important that this be discussed quickly.

Thanks!

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

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSL-FO/XSLT/XML training:    Birmingham, UK 2006-07-04/13
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML 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