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] version attribute - Re: [ubl] Minutes of AtlanticUBL T Ccall2 November 2005


OK.. It is all looking clearer that we need to do things
like keep namespaces the same for minor versions -
because we wish to use xsd:redefine for minor versions.

I now agree - sorry for being a bit of a doubter.

I retract my concerns - the whole thing together now
makes good sense to me.

All the best

Steve


>>> Grimley Michael J NPRI <GrimleyMJ@Npt.NUWC.Navy.Mil> 04/11/05 16:56:19 >>>

> "(Plus folk are rightly expecting minimal departure from the promises of the original NDR and confidence in UBL could perhaps be) damaged if too much of the NDR1 is NOT preserved in 2.0"

I certainly understand your concerns and have faith that all members of the TC take that into consideration when making these decisions.

That being said, the changes currently under discussion 'only' concern minor-versioning.

Take Care,
Mike

-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Friday, 04 November 2005 1134
To: ubl@lists.oasis-open.org 
Subject: [ubl] version attribute - Re: [ubl] Minutes of Atlantic UBL TC call2 November 2005

"Plus folk are rightly expecting minimal departure from the promises of the original NDR and confidence in UBL could perhaps be damaged if too much of the NDR1 is preserved in 2.0 (minor versioning would appear, by nature, to apply beyond UBL 1.0)."

sorry I meant

"damaged if too much of the NDR1 is NOT preserved in 2.0"

Plus I'd add that not only would a UBL-specific version attribute be proprietary as far as software is concerned but that such an attribute would be specific to a particular version of UBL too (since it doesn't exist in UBL 1.0) so applications upgrading to UBL 1.0 have to be changed a lot to deal with 2.x and application designed for 2.0 might not work with 1.0 (not just semantically but mechanically).

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 04/11/05
>>> 16:18:32 >>>
Objection regarding version attribute

I'd refer to Eduardo and Arofan's excellent XML 2003 paper http://www.idealliance.org/papers/dx_xmle03/papers/03-04-03/03-04-03.pdf 
section 4 - first paragraph
"The scope of UBL, and the potential for having several versions of the same schema extant at the same time, places emphasis on some particular aspects of versioning. First, the manageability of a versioned "package" becomes very important, because there is little or no control over the applications that use it. Users must be able to easily distinguish one version from another, and applications should be able to do the same, preferably without having to implement any functionality that is specific to one particular version. (It should be pointed out that, while XSD does offer us a "version" attribute on the schema element, there is no standard on how that field is to be used. Any versioning approach that relies on it, or similar other "version" attributes applied to various elements, is in essence proprietary.)"

I agree that a UBL specific version attribute has a downside of being 'proprietary', too specific to UBL. It does allow the attribute to appear in an instance which improves on the xsd:version attribute, but is more proprietary and has to be catered for in software in a way that is specific to UBL. This may exacerbate the impact on other standards (like ebXML) and subsets (see my previous email today), not to mention customizations (which have to have a way to show they are a customisation of a particular minor version).

Add to this the problem of derivation which needs a namespace different from the one importing it and I think there is a very strong argument for keeping the minor version number in the namespace in the case of UBL - and I see less of a reason for consigning it to a UBL-defined attribute. Then there is the problem that references to the value of the attribute have lack of precision of 'vocabulary' control (e.g. is '2.0' the same as '2:0' when version needs to be quoted outside of UBL).

Plus folk are rightly expecting minimal departure from the promises of the original NDR and confidence in UBL could perhaps be damaged if too much of the NDR1 is preserved in 2.0 (minor versioning would appear, by nature, to apply beyond UBL 1.0).

Even if we were to abandon substitution groups and derivation and deltas (unless these can be kept somehow without substitution groups in the mechanism), I'd still hope that we kept the minor version in the namespace (not least because it allows necessary precision if just the namespace and not the version can be referenced in trading partner agreements and business process specifications and likewise in customisations).

All the best

Steve

---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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