MHonArc v2.5.0b2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: FW: RN feedback
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.
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.
RosettaNetComments_1-0.pdf
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]