[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 subseth 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]