OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


-----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 the
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 any
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 account
both
tc and oasis versions?  Need further ndr rules to allow these rules to
be kept.

In addition, in [VER 9] what does 'exisiting' or 'new' mean here except
that
it is by comparision with the version mentioned in [VER 8]?  The words
'alter'
and 'new' require you to have two versions available of both model and
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 ssc
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 problem
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_workgroup
.php.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]