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
Hi Arofan,
Thanks for your feedback. Nice to know you're still lurking there!
I'm sure there will be some additional responses, but your comments
certainly help identify what we should be concerned about, and having
that background is really, really helpful.
Thanks again,
-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 mi
>nor
>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-w
>ork
>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 sche
>ma
>to reflect this).
>
>Changes to the spreadsheets cannot be so (incredibly) huge: all you n
>eed
>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 h
>ave
>stopped making sense, as we will have compromised the integrity of th
>e
>design in very serious (IMHO fatal) ways.
>
>Cheers,
>
>Arofan Gregory
>
>
>