MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ubl] urgent ndr rules question/clarification
Anne:
Anne:
Since I stopped being an active participant and a lurker, I do not
generally comment, but this is an incredibly serious issue that you
raise.
If you change this versioning scheme, you will absolutely invalidate a
lot of the underlying thinking within NDR concerning the use of
namespaces, modularity, and many other details, such as the naming
conventions. These issues were debated long and hard within NDR while I
was still active in the group, and abandoning them has some pretty
drastic consequences:
- You completely invalidate the approach to extension/customization, and
the work done in that area, as it relies on the schema exhibiting the
inheritance in a processable fashion across versions.
- You run the risk of producing non-backward-compatible changes in minor
versions, which are, under the current scheme, disallowed by the
extension and derivation features of XML schema.
- You render pointless many of the decisions about modularity and
packaging, which assumed the current NDR kind of extension/derivation
mechanism being in place. The impact of this would be a *lot* of re-work
of the existing NDR, at a minimum a lot of analysis.
- You invalidate the naming rules in NDR, vis-�-vis ebXML Core
Components spec (names across versions, even if having different,
modified content, must be dis-ambiguated by their namespaces, while
maintaining their identity and their names, as derived from the
corresponding BIE. NDR uses the extension/derivation features of schema
to reflect this).
Changes to the spreadsheets cannot be so (incredibly) huge: all you need
to know is if a specific construct is being inherited from a minor
version, or is new to the current one. (Ideally, the spreadsheets for
each version would contain only new information, but I gather that is
not how they've been constructed.)
Add a column to the spreadsheet which identifies the version of each
construct, identify the differences, and output them. Since the names of
types and elements must be the same across minor versions -
disambiguated only by their namespaces - then the names of the types and
elements are predictable.
I'm sure this is not a simple task, and I don't mean to trivialize it,
but it is worth the effort it will take. Otherwise, NDR will simply have
stopped making sense, as we will have compromised the integrity of the
design in very serious (IMHO fatal) ways.
Cheers,
Arofan Gregory