RosettaNet Comment Discussion: Versioning

["Lisa-Aeon" <lseaburg@aeon-llc.com>]

We received a comments document from RosettaNet that went through a
comparison and commenting of our NDRs.  We have broken them into sections
that go together for discussion purposes.  Each section is being sent out in
email. Please take the time to read through and comment back to the list.
Since we are so close to deadline, this is important that it get done as
soon as possible.  Thank you.

Versioning:

Discussion: On this mornings ConCall we discussed the first 4 rules and
suggestions. Here is the first section of Comments and Suggestions from
RosettaNet. Please read through and reply with your thoughts and comments.




2.2.2 Versioning

Here are some suggestion related to versioning approach:

  1.. targetNamespace MUST NOT include minor version number.


As [UBLN] major and minor version numbers are embedded in a particular
namespace that implies that changing minor version number doesn't allow
replacement of old schema with the new schema respective to keeping the same
instance documents.




Suggestions:

Enforce embedding only major version number in the "targetNamespace". This
enables RosettaNet to not enforce a schema version bumping rule: A major
version change happens only if an XML instance that was validated with a
previous version of the schema cannot be validated with the new version of
the schema. By using only the major version in namespace, needless changes
to multiple files can be avoided.




  2.. Usage of xsd:schema built-in "version" attribute


While [UBLN] forces inclusion of version information in the namespace, it
doesn't convey version of the Schema Module itself. In case when lifecycle
of the Schema Module is independent of the lifecycle of the relevant
namespace, it is useful to have an independent Schema Module version.




Suggestions:

"version" attribute of xsd:schema MUST be present and its value MUST reflect
the version of the Schema. This will allow the major.minor version available
with the schema definition for any processor that still wants to make
changes based on the minor version.




  3.. Versioning of types in Schemas


In case when lifecycle of a "type" inside a Schema Module is independent of
the lifecycle of the Schema Module, it is useful to embed the "type version"
inside the Schema.




Suggestions:

Require a new annotation for "TypeVersion" to every type definition. Example
below.

<xs:annotation>

<xs:appinfo xml:lang="US_EN">

<Constraint> Schematron constraint if any</Constraint>

<Context> Reusable type here </Context>

<CreationDate> 20/06/2003 </CreationDate>

<Keyword> Invoicing </Keyword>

<LastUpdateDate> 20/06/2003 </ LastUpdateDate >

<Definition> State the definition here </DEfinition>

<TypeVersion> 0.14 </TypeVersion>

</xs:appinfo>

</xs:annotation>







  4.. Exposing "Schema Version" via instance documents


Sometimes it is beneficial to be able to correlate a given instance document
fragment to the type definition in a particular namespace so that processing
application at the destination can take appropriate action(s).




Suggestions:

A common global attribute "schemaVersion" of the "xsd:token" type MUST be
declared as an optional attribute for all Root Schema type definitions.

Instance documents SHOULD set the value of the "schemaVersion" attribute.
The "schemaVersion" attribute MAY contain more then one value of the Schema
versions that the instance document is compatible with.







2.3.1 Rule 38

Rule: Schema location must include the complete URI which is used to
identify schema modules.




Comment: Schemas might be placed in different root directories. Also, for
security reasons it is advisable not to reveal the location of the Schemas.




Suggestions:

"schemaLocation" attribute MUST point to the imported Schema via relative
path with respect to the location where the current Schema is stored.







2.3.2 Rule 47

Rule: Each minor version must be given a separate namespace.




Comment: See discussion about versioning in section 2.2.2.




Suggestions:

Remove the rule.







++++++++++++++++++++++++++++++++++++++++++++++++++++
Lisa Seaburg
AEON Consulting
Website: http://www.aeon-llc.com
Email:  lseaburg@aeon-llc.com
Alternative Email: xcblgeek@yahoo.com
Phone: 662-562-7676
Cellphone: 662-501-7676

"If you obey all the rules, you miss all the fun."
                       -Katharine Hepburn
++++++++++++++++++++++++++++++++++++++++++++++++++++



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003
BEGIN:VCARD
VERSION:2.1
N:Seaburg;Lisa
FN:Lisa Seaburg (E-mail)
ORG:Aeon LLC
TEL;WORK;VOICE:(662) 562-7676
ADR;WORK:;;;Senatobia;MS;38668;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Senatobia, MS 38668=0D=0AUSA
URL;WORK:http://www.aeon-llc.com
EMAIL;PREF;INTERNET:lseaburg@aeon-llc.com
REV:20030924T220907Z
END:VCARD