MHonArc v2.5.0b2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: RN feedback
Title: Message
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?
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.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]