[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [ubl] [ver] a prototype that works
Daid, the annotation info doesn't appear in the instance like a namespace token will. AtG is still working out its versioning, and I am not sure my interpretation of where they are at matches yours at the moment. Also remember, atg is local, so a new type will have all new version elements.
It seems to me that even if we do a major version change this time, we would have a 2.0 namespace that imports 1.0 and only declares/defines new elements/types. Of course we also belie ved that different schema would have different versions and we would not reissue UBL as complete monolithic standards as had been done in the EDI world. If we are going to continue with monolithic updates, then we should revisit not only our versioning scheme, but our modularity and namespace strategy as well.
Mark R. Crawford
Senior Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet Representative
Vice Chair - OASIS UBL TC & Chair Naming and Design Rules Subcommittee
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components
LMI Government Consulting
2000 Corporate Ridge
McLean, VA 22102-7805
The opportunity to make a difference has never been greater
From: David Kruppke <email@example.com>
To: firstname.lastname@example.org <email@example.com>
Sent: Wed Apr 20 03:42:02 2005
Subject: AW: [ubl] [ver] a prototype that works
> But does this mean everything is given a version update - even if
> it doesn't change? That is terribly monolithic.
No, every single element for a BBIE or ASBIE has a documentation item for its version. Using this documentation a user of UBL can recognize if an element has changed or is new in UBL 1.1. (Apart from a document that lists all differences between 1.0 and 1.1)
And BTW, it would be the same procedure ATG2 uses in its NDR. Please compare "XML Naming and Design Rules Draft 1.1a, 16 February 2005" chapter 5.8.2 Minor Versions:
Since each minor version is assigned its own namespace, for conformance purposes, the fist minor version must incorporate all XML constructs present in the parent major version, and each new minor version needs to incorporate all XML constructs present in the immediately preceding minor version.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS