ubl message

Subject: [ubl] version attribute - Re: [ubl] Minutes of Atlantic UBL TCcall2 November 2005

From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
To: <ubl@lists.oasis-open.org>
Date: Fri, 04 Nov 2005 16:33:47 +0000

"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

>>> <jon.bosak@sun.com> 04/11/05 00:44:07 >>>
MINUTES OF ATLANTIC UBL TC MEETING
16H00 - 18H00 UTC WEDNESDAY 2 NOVEMBER 2005

ADMINISTRIVIA

It was decided at the close of this meeting that due to
attendance at XML 2005, we will not be holding the Atlantic
call 16 November. We *will* be holding this call at its
regularly scheduled time next week (9 November).

ATTENDANCE

Jon Bosak (chair)
Mikkel Brun
Mavis Cournane
Michael Grimley
Betty Harvey
Bryan Rasmussen
Kumar Sivaraman
Paul Thorpe

STANDING ITEMS

Additions to the calendar:
http://ibiblio.org/bosak/ubl/calendar.htm

None.

Review of Pacific and Europe/Asia calls

No comments.

Schedule review
Including attendance at April meeting in Brussels

JB: This meeting is to be hosted by CEN/ISSS in Brussels the
week of 24 April. It accidentally got dropped from the 2.0
schedule. We very much want to accept the offer to host,
but neither JB nor TM will be available to chair. We need
to know who can commit to be there.

ACTION: JB to poll the TC for attendance at the April F2F in
Brussels.

ACTION ITEM REVIEW

ACTION: JB to create the first draft of index.htm.

Status: Done.

ACTION: TC members visiting NYC in October or November to check
out the Sun facilities and see whether they are suitable for a
UBL TC meeting. JB will be coming through in mid-November and
will also check then.

Status: Pending.

ACTION: JB to post a question on ubl-dev: What do other widely
used schemas do about minor version namespace URIs?

Status: Done.

ACTION: Everyone involved in the development of the support
pieces to give JB time estimates.

JB: We have estimates for SBS from SG. We still need
estimates for code lists, HISC, and the business process
scenarios.

ACTION: MB to check with PB regarding time estimates for the
business process scenarios.

FOR THIS MEETING

NDR work session: Minor versioning. See

http://lists.oasis-open.org/archives/ubl/200510/msg00084.html

*** NOTE that as usual, voting members have a week to register
any disagreement with the decisions described below. If no
disagreement is registered, the decisions arrived at during the
call will become officially adopted by the TC. ***

Question 1: Should minor-version schemas only contain the deltas,
or should everything be redeclared (with the 'ccts:Version'
documentation component reflecting the version of individual
types).

Discussion: Deltas make clear exactly what's been changed or
added and make it easy to determine backward compatibility.

AGREED that minor-version schemas should only contain the
deltas.

Question 1.a: Should we have minor-version spreadsheets that only
capture the deltas and their relationship to the major version?

Discussion: Providing full spreadsheets for the minor version
allows someone coming in at that stage to see the whole
picture. It also sidesteps the problem of how to capture the
relationship between major and minor at the spreadsheet level
(we can just add a flag to mark the items that have been added
in the minor version).

AGREED that the minor version spreadsheets should contain the
entire vocabulary, with a flag to indicate what has been
changed or added in the minor version.

AGREED that we thank Bill Burcham for his contribution of a
method that could have been employed if we had decided that the
minor version spreadsheets would contain only the deltas.

Discussion: It may be difficult for tools to generate the
deltas (see decision on Question 1 above) from the full
spreadsheets. It's possible that the tool we use will only be
able to create major version schemas, and that we will have to
create the minor version schemas by hand.

AGREED that while we hope that tools can be configured to
create the minor version delta schemas from the full
spreadsheets, we are willing to adopt this policy even if it
means that the minor version schemas have to be created by
hand.

Question 2: Should the namespace name change for minor versions?
How about the namespace prefix?

Discussion: Our assumption is that a minor version of UBL may
add new content but will not change the meaning of anything
declared in the major version schemas. It therefore appears
that the best approach is to separate semantic identity from
versioning. But doing so will require us to specify expected
behavior of UBL processors when presented with instances
exhibiting different versioning information.

AGREED that minor versions should use the same namespace as the
major version from which they are derived (which means, for
example, that the namespace for UBL 2.0 should reference "UBL
2" rather than "2.0") and that the version should be specified
in a separate attribute TBD.

AGREED that the namespace prefix stays the same in minor
versions.

ACTION: NDR editors to propose a suitable version attribute to
be used by all UBL instances in time for discussion during the
Atlantic TC call 9 November.

ACTION: At the Manhattan F2F in January, NDR editors to develop
a specification of expected behavior of UBL processors when
encountering a version different from the one for which they
were designed. (For example, UBL processors expecting a
version 2.x when presented with an instance conforming to a
later version 2.y might be required to attempt validation
against the 2.x schemas and reject the instance if errors are
found.)

Discussion: We note that some users may not understand that the
specification of namespace prefixes in our NDRs does not
hardwire those prefixes in conformant instances.

ACTION: At the Manhattan F2F in January, NDR editors to develop
a best practice note for namespace prefixes. (For example,
"For ease of comprehension it is recommended that the prefixes
specified in our NDRs are used in instances, but applications
must be able to process arbitrary prefix declarations per the
XML Recommendation.")

Question 3: What, specifically, determines whether a new version
of the schema is actually a 'minor' or 'major' release? (If the
schema only includes the deltas, and utilizes xsd:derivation
concepts, the answer should be simpler than if the versioning is
strictly model-based.)

Discussion: We have already adopted the definitions given by
Eduardo Gutentag in his message of 18 October 2005, but we note
that his definition of backward compatibility transposes X and
Y:

c) backwards compatibility -- a schema X is said to be
backwards compatible with a schema Y if documents that
validate against schema X also validate against schema Y,
and schema X follows (in time, or in version) schema Y.

In other words, if all documents that validate against
MySchema v1.0 also validate against MySchema v1.1, then
MySchema v1.1 is said to be backwards compatible; but there
is no expectation that any document that validates against
MySchema v1.1 must also by necessity validate against
MySchema v1.0

The example shows that the definition should read "and schema Y
follows (in time, or in version) schema X."

Question 4: Is (are?) Substitution Groups still on the table?

AGREED: We will not use substitution groups for minor
versioning.

Question 5: What should be the normative version of UBL? Schema,
Model or both.

Discussion: XML inherits from SGML the doctrine that documents
are normatively specified by the combination of formal
declarations plus comments. Properly annotated schema
formalisms such as DTD (W3C), XSD (W3C), RELAX NG (ISO),
Schematron (ISO), and ASN.1 (ITU) are the standard mechanisms
for establishing the validity of XML instances; no such
standard exists for mechanically checking an instance against a
model. And since there is no way of proving that a model and a
schema describe exactly the same thing, we cannot say that both
are normative.

AGREED that UBL is normatively specified by the schemas plus
associated normative prose.

Jon Bosak
Chair, OASIS UBL TC

---------------------------------------------------------------------
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