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] Minutes of Atlantic UBL TC call 2 November 2005

I know that you expect me to chime in on substitution groups so here goes:
If we have determined that minor versions will only have deltas, how does one obtain a schema to validate against. Substitution groups allows you do that. Redefine can do some of this too (but we haven't yet gotten this to work with highly nested schemas).
Thus, it seems we are leaving the user to hand patch his schemas and then assert that they are valid to UBL 2.1, for example. Or, are we going to provide a properly edited version 2.1 to place in repositories? If the latter, then we may as well publish it, rather then the deltas. People can do a "diff" if they want to see only the deltas.
I may be missing something, but this is some quick input into the discussion. BTW, I applaud the decision to make minor versions have the same namespace as the major version and the backwards compatibility statement makes sense.
In a message dated 11/3/2005 7:44:34 P.M. Eastern Standard Time, jon.bosak@sun.com writes:


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


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


   Additions to the calendar:


   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


   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

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


NDR work session: Minor versioning.  See


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

   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

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

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

   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

   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

      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

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

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


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