OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-ndrsc] RE: RN feedback


Title: Message
Sorry, my message earlier didn't get through
See attached...
 

Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)

-----Original Message-----
From: Burcham, Bill
Sent: Monday, January 12, 2004 7:54 AM
To: 'UBL NDR'
Cc: 'Jon Bosak (Jon.Bosak@sun.com)'
Subject: [ubl-ndrsc] RE: RN feedback

Hey get this... a little bird just told me that this is no longer an issue!  The latest guideline posted by RN to the NDR has both major and minor versions in the namespace (name).  How cool is that?
-----Original Message-----
From: Burcham, Bill
Sent: Monday, January 05, 2004 6:38 AM
To: UBL NDR
Cc: Jon Bosak (Jon.Bosak@sun.com)
Subject: FW: RN feedback

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

--- Begin Message ---
Title: Message
The full RosettaNet XML Guidelines document that I had sent earlier doesn't
have this rule. We had removed it to facilitate better debugging of schemas when validating,
after agonizing over the pain inflicted by minor versions. RosettaNet still keeps the version bumping rule
on when major/minor versioning will be  applied - which means that minor versioning maintains backwards compatibility
of instance documents (validation).
 
Are there any other differences worth discussing?

Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)

-----Original Message-----
From: Burcham, Bill
Sent: Monday, January 05, 2004 6:38 AM
To: UBL NDR
Cc: Jon Bosak (Jon.Bosak@sun.com)
Subject: [ubl-ndrsc] FW: RN feedback

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

--- End Message ---


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]