Minutes of UBL TC meeting 15 August 2006

[jon.bosak@sun.com]

UBL TC MINUTES FOR TUESDAY 15 AUGUST 2006

Members attending in person:

   Jon Bosak (chair)
   Mavis Cournane
   Mike Grimley
   G. Ken Holman
   Andy Schoka
   Paul Thorpe

Members attending by phone:

   Tim McGrath (vice chair)

   The phone was open from about 09:15 to 11:25 and will be open
   again tomorrow (Wednesday) starting about the same time.

Issue review

   TM recorded all the results of this in the issues spreadsheet,
   so these are just the high-level bits:

    - Issues 15, 23, and 29 are possibly errors that will have to
      be corrected before release.

         ISS-29: Simple copying error; must talk about this
         Wednesday [but note that 29 seems to have been resolved;
         see below].

         ISS-23: It appears that EF is enforcing a CCTS rule
         (truncations of DENs are not allowed when qualifiers are
         present) and that therefore the spreadsheets should be
         corrected to fit the schemas.

         ISS-15: Appears to be a real inconsistency that may have
         to be corrected.

         ISS-11 also looks like it might need correcting.

    - We covered ISS-1 through ISS-15 as well as ISS-25 and ISS-26
      (as side effects) with results recorded in the revised
      issues list.  We will resume tomorrow with ISS-16.

UBLVersion revisited

   GKH joined us in the afternoon, prompting a continuation of
   yesterday's discussion of UBLVersion.  We eventually came to a
   general agreement on the following two points.

   1. It's an error to think of UBLVersion as a report about the
      system generating the instance, because a "UBL 2.7 system"
      is still perfectly capable of generating an instance that
      uses elements defined no later than 2.3, say (and in an
      environment with lots of different trading partners, this
      will not be unusual).  Rather, the value of the UBLVersion
      element (if it has a value) is a claim by the originating
      system that the instance will validate against any UBL
      schema whose minor version number (within the indicated
      major range) is equal to or greater than the value given by
      UBLVersion.  So a UBLVersion value of 2.3, for example, does
      not mean "I come from a UBL 2.3 system" but rather "I claim
      to be valid against any UBL schema from release 2.3 up to
      the latest major version 2 release" (because we define a
      minor version update as one that adds only optional
      elements).  Or, to put it another way, it says "I guarantee
      that you will find no elements in here defined later than
      the ones found in version 2.3." The same applies to the
      elements for profile version and subset version.

      It should be noted that the version number when applied to a
      receiving system means something different.  The expression
      "a UBL 2.3 system" means (or should mean) "a system that's
      been set up to validate incoming instances against a UBL 2.3
      schema."

   2. In light of this, we identified the following two strategies
      for providing the desired functionality.

      A. Create processing instructions to hold the values of
         schema, profile, and subset version, and add an eighth
         instance rule to specify their position in the document.
         This is the alternative favored by the group, but we
         suspect that the unfamiliarity of the construct may cause
         anxiety among users (or rather fears by vendors of
         anxiety among users).

      B. Make the three version elements optional, with no default
	 or fixed values and no value constraints.  We note that
	 option C requires no substantive change to the current
	 schemas (though it might be a good idea to revise the
	 definitions of these elements).  This is the alternative
	 recommended by the group meeting in Montréal.

Jon