Minutes of Atlantic UBL TC call 9 March 2005

[jon.bosak@sun.com]

MINUTES OF ATLANTIC UBL TC MEETING
16H00 - 18H00 UTC WEDNESDAY 9 MARCH 2005

ATTENDANCE

   Jon Bosak (chair)
   Tony Coates
   Mavis Cournane
   Stephen Green
   Anne Hendry
   Ken Sall
   Sylvia Webb

STANDING ITEMS

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

      None.

   Liaison reports

      None.

   Subcommittee reports

      HISC (StephenG): Making good progress. GKH is working hard
      on improving the format for specifying subsets; some of this
      work will be used in the proposed SBSC.  A beta of the SBS
      has been produced for the purpose of trying out the format.

      SSC (StephenG): Long discussion last week -- see the SC
      minutes.  We seem to have enough now for initial schema
      generation, but we still need TC approval of the change
      requirements; for the first phase of schema generation, we
      probably just need GXS1 and the new documentation
      requirements.  That will give us a breather whle we consider
      the more difficult minor revision NDR question and the code
      list issues.

   Team reports

      Codelist (TonyC): Haven't had a chance to get together.

      SylviaW: Note interesting discussion of enum extension on
      xml-dev.

      JonB: I'm still trying to understand the requirement.

      StephenG/TonyC: The minor revision NDR question raises
      issues similar to those of code list extension if the code
      list schema imports a previous version of the code list.

GXS1 LEFTOVERS

   Leftover GXS1 issues from week before last:

   | | Rule is missing other import possibilities:
   | |   - any codelist schemas
   | |   - cc parameters schema
   | | Add these to the rule.
   | 
   | The schemas actually do this, but it's not covered by the rule.
   | 
   | Proposal for discussion next week: Add to the rule that
   | specialized is followed by code list and then CC parameters.

   Agreed: Change "any codelist schemas" to "any code list
   schemas, in alphabetical order"; then we can adopt this
   recommendation with the understanding (as stated earlier) that
   this rule applies "as appropriate" (or perhaps better "as
   applicable").  We think that "in alphabetical order" will also
   ensure "in version order" if multiple versions are included.

   In a side discussion of the meaning of "backward compatibility"
   it was noted that the validation of 1.0 instances against 1.1
   schemas assumes that the software will know to change the
   namespace of the instance appropriately.

   For further discussion in some future meeting: The working
   definition of "backward compatibility."

   | | Also there was some discussion a while back on how
   | | to handle the capitalization of the second word in 
   | | terms of how that should be alphabetized.  Was there
   | | a conclusion on this?
   | 
   | Proposal for discussion next week: In alphabetizing, ignore case
   | (i.e., fold case), and ignore the xsd-related suffix "type" when
   | it's there purely for xsd reasons.

   TonyC: It's unnecessarily onerous to require apps to
   alphabetize attributes, which may be generated from a DOM tree;
   this should apply only to elements.

   StephenG: And namespaces.

   Agreed: Sort top level elements in schemas by the value of
   their "name" attribute.

   A discussion of the second part (ignore "type" suffix) ensued.

   StephenG: Example: Without this rule, Address would appear
   before AddressLine in the element definitions, but
   AddressLineType would appear before AddressType in the type
   definitions.  We want to keep things in the order they appeared
   in the spreadsheet.

   TonyC: In something this big, there is no useful logical order,
   just alpha.

   StephenG: We already agreed to this plan in considering a
   comment in UBL 1.0 CD2.

   JonB: As the naive user, I would find it easiest to scan in
   alpha order no matter where I was in the schema.

   SylviaW: Would be using a simple "find" anyway.

   A poll of the members present showed a majority in favor of
   simple alphabetization, but a sizable minority going with
   Stephen's argument.

   Agreed: We're inclining to simple alphabetization, but we need
   to revisit this after getting input from the whole TC.

REVIEW OF SCHEMA GENERATION CHANGES

   See

      http://lists.oasis-open.org/archives/ubl/200502/msg00056.html

   starting with "CHANGE REQUIREMENTS (1st March 2005)"

   C1, C2: DavidK objects to the requirement that the schema
   generator automatically pick up the values of supplementary
   components if these don't appear in the spreadsheet.

   StephenG: The generator has to get them from somewhere, and we
   wouldn't have these values in the spreadsheet.

   SylviaW: In C2, what's actually being asked for in some cases
   is an example value.

   JonB: We seem to be asking the schema generator to perform
   documentation tasks that only a human can do.

   SylviaW: Someone will need to provide these values, either in
   the spreadsheet or by keying them directly into EF; DavidK
   won't be able to create these on his own.

   JonB: The rule should be written to make it clear that the
   schema generator need only pick up documentation that's written
   in the spreadsheet.

   StephenG: DavidK would prefer to leave these values out of the
   documentation in 1.1.  We only had one restriction in UBL 1.0,
   and that one needed to be explained... These need to be dealt
   with on a case-by-case basis.

   Agreed: The values should be given only in exceptional cases.
   Accept C1 and C2 *without* the last clause relating to the
   values of supplementary components and deal with this later as
   part of a larger issue concerning the scope of 1.1
   restrictions.

   C3: Agreed: OK.

   C4: This is the "minor rev" issue; discuss separately.

   C5: Agreed: Accept all of the proposals for GXS1 (taking into
   account the discussion of "leftovers" above).

   StephenG: What does it mean for 1.1 schemas to be backward
   compatible with 1.0?  For example, the attributes for
   supplementary components should be all lc for the first word,
   but we have URI as uppercase already; but we don't actually use
   it in 1.0 schemas... Do we have to change the 1.0 schemas to be
   in accordance with the new rule?

   JonB: The 1.0 schemas don't change.  But this does point out
   another aspect of the minor revision issue.

   Agreed: We've done enough with the schema generation changes
   for DavidK to proceed.

   SylviaW to prepare a list of those changes for DavidK; StephenG
   to review.

   We note that SylviaW, MichaelD, MarkC, and SueP will all be in
   Kuala Lumpur next week.  It may not be useful to attempt a
   meeting while they're gone.

Left undone:

MINOR VERSION SCHEMA STRUCTURE

   See

      http://lists.oasis-open.org/archives/ubl/200502/msg00036.html
      http://lists.oasis-open.org/archives/ubl/200503/msg00007.html

   and other messages in that thread; also see the message from
   Stephen Green referenced above.

   The minutes of last week's Pacific TC call say:

   | 3. UBL Schema generation
   | 
   |    Tim - Software subcommittee pilot - the production of schemas
   |    for development of schemas for UBL 1.1.  Produce the most
   |    appropriate spreadsheet of those changes -and how much can be
   |    produced in EDIFIX and how much will require manual
   |    manipulation.

   But I'm not sure quite what to make of this.

Jon