MHonArc v2.5.0b2 -->
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
All,
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.
Regards,
Sylvia
-----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
MINUTES OF ATLANTIC UBL TC MEETING
15H00 - 17H00 UTC WEDNESDAY 24 AUGUST 2005
ATTENDANCE
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
JANUARY UBL TC MEETING
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
afternoon).
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.
STANDING ITEMS
Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm)
None.
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
approach.
JB: (summarizes the reasoning that led to the new direction;
see
http://lists.oasis-open.org/archives/ubl/200508/msg00042.html
and
http://lists.oasis-open.org/archives/ubl/200508/msg00060.html)
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
"seller."
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
stakeholders.
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
stand.
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.
NDR DOCUMENT REVISIONS
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:
http://lists.oasis-open.org/archives/ubl/200508/msg00054.html
http://lists.oasis-open.org/archives/ubl/200508/msg00055.html]
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.
PHASE 1 CONTENT MODELS
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
two?
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
off.
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
Chair, OASIS UBL TC
---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]