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: RE: [ubl] Minutes of Atlantic UBL TC call 24 August 2005


WRT the topic of Content Models in the minutes below, GEFEG's question,
should Procurement and Common models be combined in EDIFIX. 

We have had further discussions internally about this question and
subsequently believe it is best for the long term to maintain these models
separately. EDIFIX will produce a Common data model and a Procurement data
model as previously discussed in TC meetings. 

As soon as we have received a complete set of extended Procurement models,
we will begin testing the import process from spreadsheets into EDIFIX.
There will be a PSC meeting Monday, 29 August to discuss the progress and
status of these models.

-----Original Message-----
From: jon.bosak@sun.com [mailto:jon.bosak@sun.com] 
Sent: Friday, August 26, 2005 2:17 PM
To: ubl@lists.oasis-open.org
Subject: [ubl] Minutes of Atlantic UBL TC call 24 August 2005

15H00 - 17H00 UTC WEDNESDAY 24 AUGUST 2005


   Jon Bosak (chair)
   Peter Borresen
   Marty Burns
   Tony Coates
   Mavis Cournane
   Mark Crawford
   Mike Grimley
   Betty Harvey
   Anne Hendry
   Zarella Rendon
   Paul Thorpe
   Sylvia Webb


   JB: As requested by the TC, checked on availability of Sun
   meeting rooms at 101 Park Avenue in NYC, and it looks like we
   can use them for the UBL TC meeting the week of 23-27 January
   2006.  The rooms are small, so we would be betting that we
   don't get more people for that meeting than we usually do.

   MavisC: NYC might also be a good place for a Friday UBL Users'
   Group meeting (this would mean finishing up Thursday

   JB: Let's pick up the idea of a Users' Group meeting when we're
   sure we will be holding the TC meeting in NYC.

   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.


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


Liaison reports

   JB: We need a report on the TBG17 meeting in Vienna.

Subcommittee reports

   JB: PSC and TSC web pages and mailing lists are now active.

Team report: Digital signatures

   PB: No progress yet; have written to ThomasL.

Team report: Code lists

   A very compressed version of the discussion follows.

   MB: Concerned about moving away from substitution groups and
   moving away from parser validation.  Disagree that there are
   two different kinds of code lists.  We need a homogeneous

   JB: (summarizes the reasoning that led to the new direction;

   TC: There are real differences between different kinds of
   codes, and they should not all be treated the same way.  Some
   kinds of enumerations make a fundamental difference in
   processing, for example adding a new code to "buyer" and

   MarkC: Agree with MB that we don't want to walk away from the
   concept of XSD validation.  Valuable lessons to be learned from
   code lists in EDI: CLs were published as part of the standard
   in a way that customizers could subset, but nonetheless the
   validation of codes took place in a first pass.

   JB: But this first pass was the same one in which business
   rules checking took place.  That's what the proposed Schematron
   validation would allow.  We should see how this will work out;
   where are we?

   TC: Am getting together the final code list format and the
   first set of stylesheets; GKH is looking at the right way to
   express the CLs in Schematron, sent an example today; the only
   question is how the metadata is expressed.

   MB: We don't know that metadata requirments are being met in
   the new strategy.  What's most important is that we meet all
   the requirements we've acquired from a wide variety of

   JB: Agree with that, and also want to see what the user
   experience is like.  Let's give it a week and see where we

   AH: What if we include just the CLs we maintain; doesn't this
   scope the problem?

   MB: But there will still be (for example) currency codes; we
   need to get this right.

   AH: We should be considering where we draw the line.

   MB: When will we have the proposed solution?

   TC: It won't be final until MB reviews it against the
   requirements.  We need other input on what needs to be in the
   CL schema.

   [Some further discussion omitted]

   AGREED that we will keep code lists on the weekly TC agenda
   until this is resolved.

Review of Pacific and Europe/Asia calls

   No meetings last week to review.


   MavisC: The revision went out to the list on 7 August.

   [Apparently this statement (possibly heard incorrectly) was
   intended to refer to the versions sent on 11 August:


   AGREED we will give the TC one more week for editorial review.

   ACTION: MarkC to review schema import diagrams in the NDR
   document and update as appropriate.

   ACTION: JB to alert the TC that we are moving to closure on the
   NDR document.


Issue: Combining common and procurement spreadsheets in the data model

   SW: We have two spreadsheets, one for common and one for
   procurement, and we need to know whether this should result in
   one internal EF data model or two.  TimM and SG think they
   should be combined in EF.

   MarkC: We need to produce a single spreadsheet in TBG17 format;
   this should be trivial.

   SW: It is.

   JB: Why do we care whether EF maintains this as one model or

   SW: Because maintaining it as two will cause serious problems
   due to circular references.  Maintaining it as one model
   internally will have no practical consequences for the TC work.
   We can still generate two spreadsheets back out again from the
   one data model.

   AGREED: Maintain one model internally.

Issue: Documenting the spreadsheet format

   SW: We need a document that describes the architecture of the
   data models; we agreed in Ottawa to add some columns, but there
   is no document that specifies the spreadsheet format.

   JB: Someone will need to volunteer for this, and time is tight
   right now.  Can we delay this for a little while?

   SW: Yes, but put it in the schedule so that it doesn't drop

   ACTION: SW to give us a deadline for completion of a document
   describing our spreadsheet format to be inserted into the UBL
   2.0 schedule.

Issue: Order in which new content is added to existing BIEs

   PB: Have raised an issue about sequential order of elements in
   spreadsheets.  SG just added new 2.0 elements at the end of the
   existing ones; I want to put them with related elements for
   readability in the spreadsheets and schemas.  SG thought that
   this would have an impact on HISC, but GKH says not.  [See
   minutes of this week's Pacific TC call.]  But if we do this,
   there would be no way to send a 1.0 document into a 2.0 schema
   environment, though it would be easy to provide a
   transformation to allow this.

   JB: We abandoned the requirement for strict backward
   compatibility with 1.0 instances when we decided that this
   would be a major release.  If we were talking about changing
   the element names in 2.0, that would have a huge impact on
   users, but what you're suggesting is that we create an order of
   elements that makes sense to users and would increase
   readability and comprehension.

   AGREED that content modelers can locate new content in
   appropriate places in order to maintain readability of
   spreadsheets, schemas, and instances.

Jon Bosak

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

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