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
Folks
I agree it's great to hear from Arofan on this and thanks
too to Eduardo for emphasising the need to keep to
the original plan with the use of derivation in the minor
release for changes to types.
This now leaves SSC with the greater dependency on the
NDR folk to provide rules elaborating on these rules which
now have to be implemented in 1.1
The changes would put a lot of work perhaps in David's lap
for Edifix updates for Schema generation so it would have
been the original intention to ask for such NDR additions by
the earlier deadline which has now passed.
Incidentally, I've yet to receive the updated NDR for the agreed
changes (dig, dig)
Now it seems we have a window of opportunity to seek the
proper implementation of VER8 and VER9 for 1.1 if NDR folk
would provide the extra rules we need in time for the second
deadline or perhaps before that in view of the size of the changes
needed for Schema generation using both 'old' and new versions
of model data.
I think this is an exciting challenge because the benefits are
clear for the effort required - I think considerable added value
can be demonstrated both in UBL and in supporting tools.
All the best
Steve
PS I think a review may be needed of the codelist question
in the light of the need to integrate any changes to codelists with
this particular requirement for minor version methodology
>>> <Anne.Hendry@Sun.COM> 25/02/05 00:12:15 >>>
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
>
>
>