Minutes of Atlantic UBL TC call 20 July 2005

[jon.bosak@sun.com]

MINUTES OF ATLANTIC UBL TC MEETING
15H00 - 17H00 UTC WEDNESDAY 20 JULY 2005

ATTENDANCE

   Jon Bosak (chair)
   Marty Burns
   Tony Coates
   Mavis Cournane
   Mark Crawford
   Mike Grimley
   Betty Harvey
   Anne Hendry
   Sue Probert
   Paul Thorpe

STANDING ITEMS

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

      None.

   Liaison reports

      None.

   Subcommittee reports

      See Pacific call.

   Team reports

      See Pacific call.  Regarding code lists:

      MB: still looking for resolution on Marty/Tony issue...

      Mavis/MG: Looked at the email; our understanding is the TC
      wanted to separate things out and you didn't.  We agreed
      with your approach; this was captured in the minutes.

      AGREED that Marty should move ahead with the common
      approach.

   Review of Pacific and Europe/Asia calls

      No comments.

DISCUSSION OF SUBSTITUTION GROUPS

   JB: Thanks to Stephen, Mark, Tony, and Marty for a very helpful
   email discussion.  If we could have this kind of preliminary
   examination of all our difficult issues, it would make deciding
   them a lot easier.  Here's my take on this one based on what's
   been said so far.

   We appear to have two issues:

    - Use of subsitution groups for customization of document
      schemas and code list schemas

    - Use of subsitution groups for minor versioning (and note
      that the question of whether to include version info in the
      namespace is not an issue right now, though it will be when
      we design a minor versioning methodology, so we should
      either hold that issue for later or continue the discussion
      under a different subject line)

   Regarding the use of subsitution groups for customization:
   Stephen and Tony have made some very good points regarding the
   difficulty of documenting and testing changes to the schemas
   without the use of a formal method like substitution groups.
   On the other hand, I think that Mark is correct in pointing out
   that there's no need for substitution groups in the major
   version schemas that *we* release.  So I think that our goal
   should be to make sure that 2.0 is engineered in a way that
   allows others to use subsitution groups to modify the standard
   schemas; and we appear to have done this in making everything
   global. So I agree completely with Marty's last note on this:

      When a user community needs to extend or restrict UBL for
      their own reasons, it is desirable to use a mechanism that
      forces the implementer to declare the extensions
      explicitly. Substitution groups does this because in order
      to validate an instance the definition of the substituting
      type must be present. Also, the designer of the base schemas
      ensures the type consistency of the substitutable
      information.

      I believe what is being proposed is not that substitution
      groups are necessarily used extensively within UBL
      schemas. What is being proposed is that the schemas be
      designed so that the substitution group mechanism can be
      utilized in extending the schemas in a clean and traceable
      way (that is the extensions are explicit in the referenced
      schema in the instance document). If substitution groups are
      used in UBL schemas they would only need to be used in the
      code list schemas themselves to allow an unconstrained or
      enumeration constrained set of values to be used in the code
      list.

      What this requires of UBL primarily is the extensive use of
      global elements (the ones that are substitutable), and, code
      list schema design and usage that facilitates the extension
      mechanism.

   (from which I assume that we will not be using subsitution
   groups directly in either our normative document schemas or our
   normative code list schemas).

   Regarding the use of subsitution groups for minor versioning,
   in this case we are the customizers, and we need to discuss
   whether to use subsitution groups ourselves in making minor
   versions, but that discussion belongs to the time when we
   design a minor versioning methodology; again, I think our
   primary goal in 2.0 should be to ensure that we can use this
   approach if we want to.

   So to sum up, I think we should adopt as a design principle
   that everything we release should be substitution-group
   friendly in order to allow the use of substitution groups in
   customization and possibly in minor versioning.

   (Polling the group)

   MB: I support this view, but there may be a technical challenge
   if there are no substitution groups in code list schemas.
   Substitution groups require that you substitute something of
   the same type.  So there may be a need for the code list itself
   to be represented as an unconstrained normalized string with a
   substitutable actual list in order to please the various
   parsers.  This is a technical question we need to resolve; we
   might find that in order to make code lists substitutable, we
   have to have one substitution group in the code list.  But we
   will avoid this if possible.

   MG: Agree with JB. There are two separate issues, and minor
   versioning can be dealt with when we get to it.  For now, we
   must make sure that we don't do anything to preclude use of
   substition groups in the future.

   BH: Comfortable with whatever the group decides.

   AH: What MB is saying makes sense. We need to architect so that
   substition groups can be used if needed in the future.  I would
   expect to see them used with code lists first.

   PT: Agree with Mark and JB about not needing substition groups
   in the schemas we publish.  But we wanted code lists to be
   published and maintained by external organizations; how would
   this work with substition groups?

   JB: We want to engineer our schemas so that they can do that.

   PT: How does an implementation know that codes have been added?

   MB: Two ways: 1. You have a business process by which you will
   knowingly accept updates. 2. If you want to accommodate the
   revised code list without updating the schemas, you can provide
   a parallel exension until such time as you incorporate an
   update from the code list provider.

   Mark: If we are substition-group free in UBL 2.0 then I am fine
   with this.

   JB: Note the unresolved technical question raised by MB. We
   need to determine whether a substition group is required in a
   code list as published in order for the user to extend it.

   TC: We need to assure ourselves that people will be able to use
   the substition group without some hook.  We need an example.

   AGREED to adopt a design principle that a customizer should be
   able to use substition groups as part of the customization
   process.

   ACTION: Code list team to investigate whether it is necessary
   for us to embed substition groups in code lists in order for a
   customizer to extend the code lists.

ACTION ITEM REVIEW

   PENDING ACTION: JonB to revise the FAQ linked from the UBL TC
   page.

      Status: Still pending.  [This is now a work item for
      Ottawa.]

OTHER BUSINESS

   Mark: LMI can host the UBL meeting now scheduled for the week
   of 23 January.

   JB: We will discuss the meeting schedule in Ottawa, but that
   would make a good default.  It certainly works for me.

   MB: Do we have a reference set of XSD validators that we expect
   instances and schemas to pass without errors or warnings?

   Mark: Jessica tested 1.0 against five validators.

   MB/JB: We could use this information.

   Mark: Robin Cover announced that NIST has made available a
   tester against multiple validators.

   AGREED that we will try out the NIST suite for validation
   tests.

NDR WORK SESSION

   We discussed the three requests from Bryan.

   1. A reconsideration of our prohibition of XSD ANY, because
      there are regional laws requiring the inclusion of specific
      information, and we need an extensible content area to
      handle this.

         AGREED that since Bryan's schemas will almost certainly
         be customizations, the inclusion of this data should be
         part of the customization.  As a separate issue, we need
         to decide whether ANY should be allowed in conformant
         customizations themselves.

   2. Restrictions on strings in UBL content to ensure that the
      content consists of more than white space, for example
      through length or minlength facets.

         AGREED that this level of data checking belongs to the
         application.

      Mark (tangentially): If we adopt ATG UDT, then we are no
      longer importing the CC parameter schema module into the
      UDT. We should drop the CC parameter schema mudule; it's
      just trying to specify what goes into annotation
      documentation and doesn't get validated anyway.

   3. Reconsideration of our prohibition of appinfo, because there
      are many cases where one element is conditional on another;
      this would give Scehamatron (for example) the data it needs
      to do conditional/contextual validation.

         AGREED that the question of whether to include appinfo
         belongs to customization.

      Mark: We need to get Schematron into our customization
      methodology.  Perhaps Rick Jelliffe can help us with this.

NEXT WEEK

   Mostly code lists.

Jon Bosak
Chair, OASIS UBL TC