MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: Namespace URI string implications
Hello UBL TC,
I've just reviewed the messages in this thread, and I have a
couple of personal observations to make in advance of Ken's
promised document on the subject.
First, I think that it's important to recall the meaning of "minor
version." I'm deliberately stating this from memory in order to
expose the state of my understanding: A minor version is one
against whose schemas instances conforming to the previous major
version will continue to validate. So, for example, a UBL version
(let's call it 2.1 for purposes of discussion) is a minor version
if valid UBL 2.0 instances will continue to validate against new
UBL 2.1 schemas. Implicit in this definition is the idea that
minor versions can only contain additions to the previous major
version; they cannot eliminate any information items or make
mandatory any information items that were previously declared to
be optional (though they can make optional items that were
previously mandatory). In other words, every minor version schema
is a superset of the previous major version of that schema. The
point of minor versioning is to allow updates to the schemas
without requiring implementors of the previous major version to
revise all their software.
So the first thing I'd like to observe is that if the appearance
of a 2.0 namespace URI will prevent a 2.0 document instance from
validating in an environment expecting a 2.1 document, then there
can be no such thing as a minor version as we have defined it.
This doesn't just apply to UBL but to every XML vocabulary. So
either (a) we and every other XML effort are going to have to
abandon the concept of minor versioning, or (b) the factor that's
preventing the 2.0 document from validating in a 2.1 environment
is a bug in the way that namespaces are implemented, and we're
going to have to figure out a workaround for it.
The second thing I'd like to say is that I personally believe the
notion of blind interchange to be unrealistic. I simply cannot
imagine a real-world business accepting either a purchase order or
an invoice without some prior out-of-band agreement (even if it's
only a handshake or a phone conversation). Common B2C portals
like amazon.com are not examples of blind interchange, because
they enforce the input format through generation of the portal
input forms, and they rely upon payment agreements that are far
from ad hoc. If anyone can think of a real-world example of the
unconstrained blind interchange of a legally binding business
document, I'd like to hear it. This seems somehow to have become
a requirement, but I'm not sure whose it is.
Being kind of a simple-minded guy, therefore, I conceive this
issue in terms of the following scenario and its two basic forms.
Scenario: Company A has implemented 2.1 in software, while company
B is still at 2.0. A and B have thought this through together and
have decided that A can do without 2.1 items in 2.0 instances from
B and B can ignore the added items in 2.1, thus enabling B to
avoid a software upgrade.
Situation 1: B sends A a 2.0 document.
Solution for Situation 1: A's input filter peeks at B's
document and changes the namespace to 2.1 before processing in
order to fool its 2.1 software into handling it. (By our
definition of minor version, a valid 2.0 document is, except
for the namespace declaration, also a valid 2.1 document.) We
can characterize this as an XSLT solution if we want, but the
fact is that it could be done with sed or perl or even by hand.
Note that we already considered this approach when discussing
customization two years ago in Hong Kong; from my notes of that
session (published to the TC that week as
chair-opinion-20040513.pdf):
Use case 2
- An XYZ industry profile is developed by defining XYZ
schemas that are proper subsets of the UBL 1.0
schemas. The definition of �gproper subset�h is
that any valid XYZ instance is also a valid UBL 1.0
instance.
- Action for UBL TC: Because the XYZ instances will carry a
non-UBL namespace, we need to (or should) develop a
simple technique whereby XYZ instances can be made to
look to off-the-shelf UBL 1.0 applications like UBL 1.0
instances. Perhaps this could take the form of a
configuration file recommended for inclusion in every
conformant UBL 1.0 processor that will allow it to
recognize that the XYZ namespace is in fact a subset of
the UBL 1.0 namespace and substitute the UBL 1.0
namespace for the XYZ namespace as the first step in
instance processing.
Note also that any scenario in which A's input filter can peek
at the namespace URI before validating it is a scenario in
which it can peek at a version attribute or element before
validating it. So I don't see why the version info has to be
in the namespace URI.
Situation 2: A sends B a 2.1 document.
Solution for Situation 2: An XSLT filter (or perl script or
whatever) at B strips out the information items not in 2.0
(thus changing it into something indistinguishable from a 2.0
instance) *and* changes the namespace URI back to 2.0 so that
B's software can process it. This is presumably something like
what Ken is going to propose to us. If so, I'd like to
recommend that the appropriate XSLT filter be made part of each
minor version release. Note again that if you can believe in
an input process that can peep the namespace URI, you can
believe that it can just as easily (or darn near as easily)
peep a version attribute or element. So as before, I don't see
why the version info has to be in the namespace URI.
The only way I can imagine Situation 2 working in a blind
interchange environment is if B, upon receiving a 2.1 instance
from a previously unknown potential partner A, responds with a
message to the effect that information items beyond those
specified in 2.0 will be ignored, continue anyway? -- something
like what you get when you open a current word processor document
in an old version of the software. But again, I find it hard to
imagine this working effectively in real life.
Jon
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]