Minutes of Atlantic UBL TC call 6 April 2005

[jon.bosak@Sun.COM]

MINUTES OF ATLANTIC UBL TC MEETING
15H00 - 17H00 UTC WEDNESDAY 6 APRIL 2005

ATTENDANCE

   Jon Bosak (chair)
   Mikkel Brun
   Marty Burns
   Tony Coates
   Mavis Cournane
   Stephen Green
   Anne Hendry
   David Kruppke
   Sylvia Webb

STANDING ITEMS

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

      None.

   TC meeting in Hangzhou

      MavisC and AnneH got the message 30 March from CNIS
      regarding meeting logistics but did not receive the
      invitation letter sent from CNIS two days earlier.  Since
      both messages were sent from exactly the same address to
      exactly the same list of addresses, and some of us did
      receive both of them, the reason for this is a mystery.

      ACTION: JonB to send invitation letter and logistical
      information to the whole ubl list.

   Liaison report: UBL in Denmark

      MikkelB: More than one million UBL 0.7 invoice messages have
      now been exchanged in the public sector, and a lot has been
      learned in the process.  An eventual transition to current
      UBL schemas is in the works.  On 18 March, the Danish group
      presented on their UBL experiences at an IDA workshop; the
      presentation was well received.  The group will also be
      presenting on their experiences with UBL at the May XTech
      2005 conference in Amsterdam. The Danish XML Committee has
      approved the formation of a Danish UBL Localization
      Subcommittee and is ready to proceed with its formation
      within the UBL TC.

      ACTION: MikkelB to send info (co-chairs, etc.) to JonB; JonB
      to propose DKLSC formation to the TC.

   Subcommittee report: SBSC

      StephenG: The SBS has been updated to what we need for
      review; a link will be sent out after the SC has had a
      chance to review the latest draft, which can be found in the
      documents section of the HISC page.  (HISC is being used for
      this because Kavi will not allow publicly visible documents
      on the SBSC site.)

      ACTION: JonB to resume the discussion with Altova.

   Team report: Code lists

      TonyC and MartyB have reached an impasse regarding the
      nature of the CL document.  For example, they do not agree
      on whether there are parts of the CL spec that should only
      relate to UBL (because of UBL's use of CCTS).

      JonB: We need to escalate this to the TC.

      AGREED: We will pick up code list issues after several of us
      return from New Orleans at our meeting 4 May and then give
      these issues priority treatment (operating in parallel with
      the content and localization issues being worked on in
      Hangzhou the week of 9 May) until we have resolved them.

      ACTION: MartyB and TonyC to create a briefing package
      summarizing the issues for the TC and send it out the week
      of 25 April so that we can prepare for the discussion.

NDR WORK SESSION

   We began a discussion of the issues list posted by Stephen Green:

      http://lists.oasis-open.org/archives/ubl/200504/msg00003.html

   We were primarily interested in the impact on users of
   incorporating the changes suggested by Mark for "UBL 2.0" into
   what we've been calling "UBL 1.1".

   Q1 -- Would be easy, since no current 1.0 instances would be
   affected.

   Q2 -- Would actually break some instances.  Question: what does
   ATG intend to do here?  And do we actually have any lowercase
   acronyms in element names, or any acronyms with mixed case?

   AGREED: We need to know from Mark what ATG's position is, and
   we need to review 1.0 to see what would actually be affected.

   (Note that there is no Q3.)

   Q4: Question for Mark: If this is "unenforceable", then why put
   it in 2.0?  Is this rule here for alignment with ATG?

   Q5: Similar to Q1 in the sense that if it were done, now would
   be the time to do it.

   StephenG: This is just badly worded and doesn't need to change.

   Q6 is resolved.

   Q7: The SSC says: this appears to be impossible to implement.
   We find that very odd and need to understand from Eduardo and
   Arofan what we're missing here.

   ACTION: JonB to arrange a meeting to discuss this.

   Q8: It appears that the rule is correct; it's our
   implementation of it in 1.0 that's in error.  DavidK: This
   wouldn't change element names, just the names of complex types.
   Question: Can we correct our implementation of the rule without
   creating backward incompatibility?  Appears to depend on
   whether the processing system is type-aware; if it is, then the
   corrected schemas would not be backward compatible.

   JonB: So this is another case where we're clear on what needs
   to be done but afraid of breaking backwards compatibility.
   What if we renamed UBL 1.1 to 2.0 and incorporated the
   corrections that create theoretical incompatibilities but
   wouldn't actually affect very many users at this point?

   Arguments for renaming "UBL 1.1" to "UBL 2.0"

    - It would finesse the current problem we're having
      implementing 1.1 according to our NDRs for minor versions
      (though this doesn't actually get us very far, because if
      there are problems here, they will need to be resolved
      before we can issue another version anyway)

    - It would recognize the major expansion of content that we're
      getting as a result of the IDA/OGC input, the JPLSC/ECALGA
      input, and the addition of Certificate of Origin; whatever
      we call it, the next release will be about twice the size of
      1.0

    - It would allow us to make some technically incompatible
      changes before they become incompatible in practice; that
      is, the incompatibilities would affect few users at this
      time while preventing much larger problems farther down the
      line

    - It would align our next release with the ATG CCT schemas

    - It would allow us to align with ATG NDRs on the issues in
      which we're already in agreement

   Arguments against renaming "UBL 1.1" to "UBL 2.0"

    - It might confuse people who have been discussing the timing
      of a possible transfer of the UBL work to UN/CEFACT

    - It might encourage people who think that we have taken the
      wrong approach with basic NDR choices to lobby us for
      fundamental changes in the upcoming release instead of
      waiting for the empirical evidence we will be gathering over
      the next couple of years of implementation

   Rebuttal to arguments against renaming "UBL 1.1" to "UBL 2.0"

    - This kind of relabeling happens all the time in OASIS; look
      at the ebXML specs

    - If renaming were really a problem for UN/CEFACT discussions,
      it would have become apparent in the change from "1.0" in
      the initial round to "1.1" now, but it appears that the
      people we're talking to are smart enough to make the
      adjustment

   This discussion will be continued next week.

Jon