MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Namespace URI string implications
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]