RE: [ubl] urgent ndr rules question/clarification

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

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
>
>
>-----Original Message-----
>From: Anne.Hendry@Sun.COM [mailto:Anne.Hendry@Sun.COM] 
>Sent: Thursday, February 24, 2005 11:43 AM
>To: ubl@lists.oasis-open.org 
>Subject: [ubl] urgent ndr rules question/clarification
>
>Regarding rules
>
>[VER 8] a ubl minor version doc schema must import its immediately
>preceding version document schema.
>[VER 9] ... new ... existing ... limited to the use the use of
>xsd:derivation and xsd:restriction ...
>
>The implication of these rules may be quite drastic in terms of being
>able to
>generate schemas programmatically and are not sure if we can do this
>with the
>spreadsheets we have as we'd need to either include the old ss into t
>he
>new ss
>by adding new columns or import both ss into ef.
>
>For 1.0, since the ss and schemas were not aligned, then there would
>need to
>be a regeneration of 1.0 model within ef from the 1.0 schemas, and an
>y
>incompatability there woudl cause a problem.  Or, could generate a
>schema that
>imports the old one and then generate a ss and try to do a diff.
>
>Do we really want these rules?  It's one possible approach to schema
>versioning,
>and if doing schemas by hand may work, but doesn't fit an automatic
>generation
>process such as the one we are persuing.  You also would need a whole
>host of
>additional ndr rules.  For example, how does this rule take into acco
>unt
>both
>tc and oasis versions?  Need further ndr rules to allow these rules t
>o
>be kept.
>
>In addition, in [VER 9] what does 'exisiting' or 'new' mean here exce
>pt
>that
>it is by comparision with the version mentioned in [VER 8]?  The word
>s
>'alter'
>and 'new' require you to have two versions available of both model an
>d
>scheams.
>Reading behind this, it seems this is an implementation of
>customization,
>and is a nice idea, and has value, but the amount of work from both s
>sc
>and
>ndr to implement these rules cannot be done in the timeframe we have.
>
>A better way to achieve similar results maybe be to build a test db
>of valid examples to test back compatibility.  If the desire is to
>demonstrate
>customization methodology with these rules then we have a larger prob
>lem
>for 1.1.
>
>
>- SSC
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster
> of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgr 
>oup
>.php.
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup 
>/ubl/members/leave_workgroup.php.
>



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.