FW: RN feedback

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

Title: Message

In response to Jon's CSC call summary http://lists.oasis-open.org/archives/ubl-csc/200312/msg00057.html. Specifically "2003-1212-04 RosettaNet NDR input"... what follows is a message I sent mid-December that might have gotten lost in the shuffle.  Aside from the scheduling issues, I think on the substance level there may be hope.

 

-----Original Message-----
From: Burcham, Bill
Sent: Wednesday, December 17, 2003 1:01 PM
Subject: RN feedback

The most contentious issue I think is on line 100:

1. targetNamespace MUST NOT include minor version number.

As [UBLN] major and minor version numbers are embedded in a particular namespace that implies that changing minor version number doesn't allow replacement of old schema with the new schema respective to keeping the same instance documents.

Suggestions:

 

Enforce embedding only major version number in the "targetNamespace". This enables RosettaNet to not enforce a schema version bumping rule: A major version change happens only if an XML instance that was validated with a previous version of the schema cannot be validated with the new version of the schema. By using only the major version in namespace, needless changes to multiple files can be avoided.

UBL has no such requirement, namely, that schemas be "replaceable".  Quite to the contrary, UBL views it as a grave error to allow users to confuse one schema version for another.  UBL supports flagging this sort of error by ensuring that a namespace name identifies a version of a schema for all time.

So if we imagine a user (of the standard) with a set of valid instance documents, and further we imagine that the user will need to validate some subset of those in the future, then under the UBL model the user would need available possibly more schemas than under the RN proposal.  I see this as a minor cost for a user to pay for the increase in specificity.  Storage is cheap.

The two approaches have no difference where it counts: in XML processing logic.  UBL specifies that minor versions of the schema within a major version of the schema be backward compatible.  Where "backward compatible" means: an instance document valid w.r.t. a given major/minor version continues to be valid w.r.t. subsequent minor versions within the major version.  NB: backward-compatibility of the schema looks like forward-compatibility of the valid instance documents.  RN appears to concur with this notion.  If you reread the suggestion in blue above you see that this must be so since RN wants to support changing (updating) schemas while retaining validity of instance docs.

So given all that, now that I've had more time to ruminate on this, perhaps we could talk RN into it.  Feel free to forward this thread to the RN folks.  Maybe it's worth restarting the dialogue.

Bill Burcham Sr. Software Architect, Integration Software Development Sterling Commerce, Inc. 469.524.2164 bill_burcham@stercomm.com

RosettaNetComments_1-0.pdf