OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Minutes of Atlantic UBL TC call 19 October 2005

15H00 - 17H00 UTC WEDNESDAY 19 OCTOBER 2005


   Peter Borresen
   Jon Bosak (chair)
   Marty Burns
   Tony Coates
   Mavis Cournane
   Michael Dill
   Mike Grimley
   Betty Harvey
   Anne Hendry
   Sue Probert
   Zarella Rendon
   Andy Schoka
   Paul Thorpe
   Sylvia Webb

   The meeting was quorate.


   Additions to the calendar:


   Liaison report: ebBP TC

      JB: Note that we have been asked for input.

   Subcommittee report: TSC

      AS: A dial-in capability will be provided at this week's TSC

   Team report: Code Lists

      TC: I have an example that SG sent me today.  I have 1.0
      schemas, and will have (1) original style, (2) 2.0 style
      enumuerated/validated, and (3) 2.0 style unvalidated; will
      see what happens with the different example.  Not sure
      exactly what GKH is doing, but don't think we're working at
      odds.  Will engage GKH after am done with latest.

   Review of Pacific and Europe/Asia calls

      No comments.

   Schedule review

      PSC: SW: We have the content, it's just not clean enough
      yet; SG hopes to be able to work on this over the next week,
      but it's highly unlikely we will make the 24th.

      Catalogue: JB: I haven't been given a reason to think that
      catalogue will slip.

      index.htm: JB: How necessary is it to talk about methodology
      the way we did in 1.0?

      SW: Just point to previous writings.

      AS: It's useful to know... so include a link to 1.0.

      ACTION: JB to create the first draft of index.htm.


   ACTION: TC members visiting NYC in October or November to check
   out the Sun facilities and see whether they are suitable for a
   UBL TC meeting.  JB will be coming through in mid-November and
   will also check then.


   ACTION: JB to create a schedule for UBL 2.0 supplementary



   UBL vice chair

      AGREED: Tim McGrath is appointed the UBL vice chair to
      replace Mark Crawford, who has had to leave active
      membership due to a change in employers.

   NDR editors

      AGREED: Mike Grimley is appointed Lead Editor of the NDR
      document.  Mike and Mavis will both be listed as editors
      when the document is published.

   UBL QDT module

      From Pacific TC minutes:

         Problem: An unintended consequence of adopting the ATG
         UDT is that the data model is not compatible with the UBL
         UDT model, so we will need a UBL QDT that matches the ATG
         UDT. This would have been an SSC task, but TonyC, SG, AH
         are all having problems attending.

      SW: Needs to be done urgently; this is in the critical path
      for schema generation.  The problem is that the ATG UDT
      starts at the ACC level, while UBL starts at the BIE level.
      As a result, the model structure is not the same.  QDTs are
      based on UDTs; we do not have a UBL UDT model, and in
      previous discussions in the PSC, TM and others were opposed
      to creating one, wanting to use the ATG model, which is not
      in spreadsheet format but exists only in Edifix.  So we
      cannot create UDTs.  Since the UDT struct is coming from
      CEFACT unchanged, we now need a QDT model that is the same
      in structure.

      MC: So would we need new NDRs for UDT schema?

      SW: We did not see any changes to the rules, just the number
      of spreadsheet columns and where data is put in those
      columns.  There is no spreadsheet version of the ATG model;
      our users will need one.

      JB: We're not providing spreadsheets of the UDT, so why do
      we need one for the QDT?

      SW: If not provided as a spreadsheet, we would need to know
      that it won't change.

      JB: So we either create one hardwired version through EF
      programming or we have to come up with a spreadsheet format
      for this.

      SW: Yes, and note that the QDT is something that gets added

      JB: So we need a spreadsheet format for this.  Volunteers?

      BH: Not a CCTS expert, but willing to help.  Does this
      require a tech person?

      SW: Yes; you need to have some understanding of CCTS 2.01.
      The ATG2 version is a CCTS data model; looks like UML class
      diagrams.  Our fallback is to do this programmatically, but
      this would prevent further changes and would take longer
      than a week.

      ACTION: JB to appeal to the list for volunteer(s) to develop
      a QDT spreadsheet.

   Code lists

      From Pacific TC minutes:

         Question: are we going with the UBL 1.0 code list
         structure for the code lists that were in UBL 1.0?  Or do
         we use the structure of the code lists that we have
         agreed to adopt from ATG2?

      JB: What's the difference?

      ACTION: SW to investigate the difference between the
      structure of the enumerated code list schemas we've agreed
      to incorporate from ATG and the ones that were included in
      UBL 1.0 and provide her findings by the end of week.

   Minor versioning: see MG's issue list:


      JB: Note answers to MG's questions 3 and 3a from EduardoG:


      AGREED to accept EG's answers to 3 and 3a.

      MB: We will need substitution groups in order to implement
      the original customization document.

      JB: Noted; relates to MG's question 4.

      MC: We also have a straw proposal from Bill Burcham [off the
      list].  It assumes that we're doing versioning from the
      model rather than the schema and is based on spreadsheets.

      JB: So this is an additional question: Shall the models be

      MC: Another question is: Do we still want to do minor

      JB: Well, we have to do minor revisions; the question is
      what to call them.  If we can't figure out how to do minor
      versioning properly speaking, then we'll either assign every
      version an integer or we'll change what we mean by
      fractional version numbers.

   Discussion of MG's Question 2: Should the namespace change for
   minor versions?

      MG: Agree with Mark Crawford: as long as it's backwards
      compatible, the namespace URN should not change; this makes
      it easier for implementers.

      MB: Agree; if the difference is just extensions, you should
      not be penalized if you've already implemented the major

      JB: There are two sides to this.  If the function of a
      namespace is to mark semantic distinctions, which was the
      original idea, then clearly you don't change the namespace
      for a minor version, because everything that was in the
      major version still has the same meaning.  This is how I was
      leaning before a recent discussion with Nikola Stojanovic of
      RosettaNet.  RN discussed this in depth and came down
      strongly on the side of assigning each minor version its own
      namespace.  The reasoning is that a namespace URN tells a
      processing application what to expect.  If the URN says
      version 2.0, the app expects not to be surprised by elements
      that are not in 2.0.  So a 2.1 document that says "2.0" is
      basically lying to the app about what it can expect to see.

      MG: The assumption is that the app should ignore an element
      it doesn't know about.  This is just good practice.

      MB: Like other apps.

      TC: But the fact is that namespaces are overwhelmingly used
      to provide version information about schemas.  There's no
      other standard way to do this.

      MB: Schema location is used for this.

      TC: No, the location is generally thrown away.

      JB: And replaced by the location on the machine where the
      schemas are installed, for example.

      TC: So really, there's no other way to tell.

      BH: How about a version attribute?

      TC: But that's not standard.  In practice, there is no
      standard piece of the infrastructure that looks at a top
      level attribute and knows to use that schema.  We would be
      asking everyone to use the structure we define.

      JB: We could have an attribute that at least tells UBL
      applications what to expect.

      ??: It would help to know what other widely used schemas do
      about this.  We know that RN changes the URN to reflect
      minor versions and we've heard that OAGIS does not.

      ACTION: JB to post a question on ubl-dev: What do other
      widely used schemas do about this?

   ACTION: NDR editors to post a revised issues list including the
   new question about which is normative (model or schema) and
   information about BillB's proposal.

   The next time that both NDR editors can attend the call is 2
   November; we will schedule a full discussion of minor
   versioning for that meeting.

   MD: Concerned that someone in another environment can carry the
   same semantic information, for example using RELAX NG.

   JB: We already do that with ASN.1 and would like to see more,
   but there can only be one normative form of the schemas
   (relates to question to be discussed 2 November).

Jon Bosak

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]