Minutes of UBL TC meeting 14 August 2006

[jon.bosak@sun.com]

UBL TC MINUTES FOR MONDAY 14 AUGUST 2006

Members attending in person:

   Jon Bosak (chair)
   Mavis Cournane
   Mike Grimley
   Andy Schoka
   Paul Thorpe

Members attending by phone:

   None.

   The conference line was live from about 09:05 to about 11:45
   and then again from about 13:30 to 15:00.  One person reported
   difficulty dialing in, but a test from a cell phone confirmed
   that the bridge was up at our usual number (see the agenda).

Welcome and overview

   No SC or team reports.

Normative schedule review

   See http://lists.oasis-open.org/archives/ubl/200608/msg00031.html

   JB: This is a very tight schedule.  There are a lot of items to
   hand in with the submission.  In particular, we need
   organizational members to testify that they are "successfully
   using" UBL 2.0 per the OASIS TC process.  Note that the meaning
   of "successfully using" is designedly fairly vague and can
   cover anything from active consideration to full production.

   Several members representing OASIS organizations committed to
   getting such a statement from their respective employers.

   ACTION: JB to put out a notice to the list requesting
   "successful use" statements.

Support package structure and scheduling

   The group went through the new support schedule template and
   briefly discussed each item.  It turns out that we need a lot
   of status reports before we can plan much further, specifically
   the following:

      Danish use cases and example instances (Borresen)
      Sample business rules expressed in schematron (Borresen)
      Output stylesheets (maybe by reference) (Holman)
      Input Xforms (Borresen)
      UML and EF data models (pointers) (McGrath)

   We hope to have better information on the status of these items
   when joined by other TC members later in the week.

   AGREED that we want to set a date of completion for the first
   release of the Support Package after looking at the status
   reports and then to publish whatever's ready by that date, in
   keeping with our previously agreed plan to publish the SP
   periodically as a living document.

   The NDR row was moved from the first draft of the normative
   schedule to the top of the SP schedule and moved forward two
   weeks so that the first 60-day review can be finished in time
   for comment disposition in Singapore.

   Further discussion of the Support Package schedule was deferred
   till Wednesday.

IPR transition

   Refer to the IPR Transition page at OASIS:

      http://www.oasis-open.org/who/ipr/ipr_transition_policy.php

   JB: Under the IPR policy adopted by OASIS April 2005, we get
   till April 2007 to either adopt a revised IPR policy of our
   choice or automatically go out of existence.  So we really
   ought to get this over with.  We get three choices for the TC's
   IPR policy: RAND ("Reasonable and Non-Discriminatory," i.e.,
   undefined); Royalty-free on RAND terms; and Royalty-free on
   Limited Terms.  RAND is directly contrary to the charter of the
   UBL TC, which has always promised users a royalty-free
   Standard.  Of the two remaining IPR policies, the one that's
   closest in intent to our historical charter is RF on Limited
   Terms.  (The name refers to limits put on the licensor, not the
   licensee.)

   AGREED: Recommend to the TC this week that we request OASIS to
   transition the UBL TC to RF on Limited Terms and ballot the
   question next week (beginning 21 August).

Instance rules in NDRs

   IND1-IND7 state rules for UBL instances.  After some
   discussion, it was determined that these items are not schema
   naming or schema design rules.  Rather, they are document
   constraints of the sort that would be provided by the schemas
   if the schema language that we are using was capable of
   supporting them.

   AGREED to move the IND rules out of the NDR document and put
   them into the UBL spec as "additional constraints," noting that
   we are not creating new rules here but rather just moving them
   in from an existing OASIS Standard (1.0 NDR).  [We later
   realized that we could also keep these in the NDR document with
   a suitable adjustment to the language that sets forth the
   purpose of the document.]

   AGREED to remove RED1 from the NDRs.

The UBLVersion element

   Once we untangled the language relating to this element from
   the question of instance rules in NDRs, there were seen to be
   two issues here: the direct problem that the element was
   supposed to be mandatory (minoccurs=1) but through a clerical
   error ended up optional (minoccurs=0), and the wider problem of
   how the application is supposed to choose a schema based on the
   value of UBLVersion when it must already have chosen a schema
   to begin parsing the document.  And this in turn made us
   realize that we weren't entirely clear on the use cases this
   element was intended to address.  We also discussed the
   reasoning behind giving the element a default value rather than
   none at all.

   Here's a decision tree we started to sketch out in order to
   understand the question of default value vs. no default value.

   Scenario I: A 2.0 document is sent to a 2.1 system (and the 2.0
   data is enough for the receiver's business process)

      Case 1: A default value for UBLVersion is hardwired into the
      validating schemas

         Alternative A: The element is empty: then the 2.1
         validating schema incorrectly contributes "2.1" to the
         value of UBLVersion (this is a good reason for
         questioning the declaration of a default value)

         Alternative B: The element correctly says "2.0": then the
         receiver's software is given the correct versioning info
         and can act on it (if it's got some way of peeking at the
         value before beginning the parse)

      Case 2: A default value for UBLVersion is not hardwired into
      the validating schemas

         Alternative A: The element is empty: then the 2.1
         validating schema doesn't know what it's got

         Alternative B: The element correctly says "2.0": then the
         receiver's software is given the correct versioning info
         and can act on it (if it's got some way of peeking at the
         value before beginning the parse)

   Scenario II: A 2.1 document is sent to a 2.0 system (and the
   receiver is OK without knowing the meaning of the elements in
   the document that were added in 2.1)

      If there are any 2.1 elements, the document won't validate
      against the receiver's 2.0 schema regardless of the value of
      UBLVersion

   MB contributed the thought that the value could be declared as
   a decimal with format "X.X" and given a range constraint.  For
   example, 2.0 schemas could require UBLVersion to be of type
   decimal with a minimum value of 2.0 and a maximum value of 2.0;
   2.1 schemas could require it to have a minimum value of 2.0 and
   a maximum value of 2.1; etc.  This would eliminate the problems
   associated with an empty UBLVersion element.

   At this point we decided to postpone further consideration of
   this issue till later in the week in order to get other members
   into the discussion.

   We noted that VER15 language will need to be revised to reflect
   what's been correctly specified in the schemas.

Jon