[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Coordination Call 16 January 2004
The 16 January UBL CSC coordination call will take place
7 a.m. California time at the following number:
#############################################
STANDING INFORMATION FOR UBL CONFERENCE CALLS
U.S. domestic toll-free number: (866)839-8145
Int. access/caller paid number: (865)524-6352
Access code: 5705229
#############################################
As usual, the call is officially a CSC conference, but
participation is open to all interested UBL TC members.
Issue 2004-0109-01
"We have not yet settled on regular times for either the
Atlantic or Pacific calls, but the times that are starting to
look most likely in the future are 16h00-17h00 California time
on Mondays or Thursdays for the Pacific call and one of the
slots starting at 11h00 or 12h00 California time on Mondays for
the Atlantic call. I am inclined to favor a schedule that
would put the Atlantic call on Monday middays in California and
the Pacific call on late Monday afternoons in California
(Tuesday morning in Asia), the idea being that I could have the
outcomes of the Atlantic meeting ready as input to the Pacific
meeting a few hours later.
I would like some feedback on this plan from the participants
on the call 9 January."
Status (2004.01.09)
NDR has agreed to change its meeting time to 12:00 - 1:00pm.
2003-1212-01 Code list ownership clarification
Issue
Code list ownership (mechanism, population, identification)
needs clarification.
Status (2004.01.08)
We seem to be largely in agreement on what follows. There
are still some things that need to be resolved; see end of
this item. I leave it to the judgment of the people on the
call as to whether these remaining issues can be carried
forward for a while.
Outcomes (2003.12.19)
We think that this describes how it's going to work:
- LCSC produces the code list catalogue that identifies
which code lists need to be included in UBL and provides
the enumerated values that will be used to populate the
code lists.
- CLSC develops:
- A standard data model, expressed in prose, for the
code lists to be used in UBL; we hope that this model
will be adopted outside of UBL as well, but its basic
requirement is to accommodate the code lists in the
UBL code list catalogue and the values provided by LC.
- An XSD realization of this data model constructed
according to schema naming and design rules specified
by NDRSC but lacking any actual code list enumeration;
call this a "code list template."
- NDR checks the code list template against the UBL naming
and design rules and returns an approved code list
template back to CLSC for inclusion in the UBL Code List
technical specification.
- TTSC instantiates the code lists in the LCSC catalogue by
generating schemas that incorporate the values provided
by LCSC in the format defined by CLSC as approved by
NDRSC.
Issues carried forward (2003.12.19)
- We need to reach out to external code list agencies to work
with us; could this be a job for the Liaison SC? For the
MoU/MG?
Discussion (2004.01.09)
EbSC might be the right forum. We should also put forward a proposal to TC154 to work with us.
Mark would like to see a commitment that we will put this code list template XSD forward as an OASIS standard. Eduardo has some reservations that if we try to work too much outside then we may have to compromise our solution. There seems to be some confusion on who is preparing the specification and we need to confirm with CLSC.
- We need to address the question of conformance testing
criteria.
Discussion (2004.01.09)
TTSC can't do conformance testing until we know what normative conformance is. They need clarified detailed definition of normative conformance. EG says that conformance is others conformance to our approach, not UBL conformance. There was a general discussion regarding the differences between customizations of the model and customizations of the XSD and which are appropriate.
Decision (2004.01.09)
The consensus is that this needs to be decided at the F2F to get everyone involved and we would focus on fostering a discussion thread between now and the F2F to air the issues.
- CLSC is still debating whether the W3C Schema expressions
should be a normative annex or a sibling chapter to the "Code List" data
model. We want to promote the UBL Code List technical
specification to other technical non-XML domains
(e.g. database implementations of code lists) and not give
the impression that it is solely for W3C Schema
implementations.
Discussion (2004.01.09)
Mark thinks that the schema should be the normative piece since this would be consistent with UBL 1.0. As with the previous discussion, there is a question regarding how you can check conformance with a data model. CL is checking with NIST to see how you could get conformance. Mark asked "Why do we care if people conform to the data model when our normative output is XSD?" There seemed to be some support for this sentiment but no decision was reached other that to include this as part of the "what is normative" debate.
- The methodology for extending/customizing code lists is
still undefined. We want users to be able to modify the
code lists, but sentiment appears to be leaning toward the
view that any change to a code list means, in effect, that
the UBL schema that references the code list is actually a
different schema. This raises the question of what it means
to be compliant. One position (upon which at least Ken and
Jon agreed during the call) is that we specify the template
and the method for unique identification using namespace
URIs, and that's the end of UBL's responsibility in this
area. The URI specification policy could be a work item for
CLSC. But at this point, ownership of the code list
customization and deployment methodology/guidelines is still
a coordination issue.
2003-1212-02 Schema compliance to NDRs
Issue
We need an owner for "review of schemas to ensure they
conform to NDR rules."
Outcomes (2003.12.12)
The responsibility for reviewing the schemas for NDR
compliance clearly belongs to NDR. The key questions are:
1. Who in the NDRSC is actually responsible for doing
this?
2. How far are they empowered to make judgments on their
own? To put it another way: how and when do they
escalate resolution on particular points to a larger
group?
Assignments (2003.12.12)
- NDRSC to identify and empower someone willing and able to
perform the NDR compliance function (or report that we
have a resource problem).
- NDRSC to specify an escalation plan for rule
interpretation and conflict resolution.
Outcomes (2003.12.19)
This did get discussed during the NDRSC meeting 17 December,
and I was supposed to copy the decision arrived at into the
coordination issues list at this point, but I can't find a
copy of the NDR minutes for that date.
2003-1212-04 RosettaNet NDR input
Issue
We have in hand a set of suggested revisions to the UBL NDRs
submitted by RosettaNet in early September:
http://lists.oasis-open.org/archives/ubl-lsc/200309/msg00002.html
We also have the latest RosettaNet NDRs:
http://lists.oasis-open.org/archives/ubl-ndrsc/200312/msg00010.html
We need to figure out how we are going to handle these inputs.
Status
See
http://lists.oasis-open.org/archives/ubl-ndrsc/200312/msg00002.html
The basic problem here is that the comments were received
several months too late to be considered in the discussions
of NDRs for UBL 1.0. Now the question is: what (if
anything) can be done to promote convergence at this late
date?
Outcomes (2003.12.12)
The coordination call didn't come to any conclusion about
this, so we'll need to carry it forward. Here is what I
think we need to know in order to arrive at some kind of
decision:
For each area of difference identified in the September
document from RosettaNet:
- Does this still apply to the final NDRs?
- If so, do we agree with the suggested change in
principle?
- If we do, what would be the practical impact of
changing UBL NDRs to align with the RosettaNet
suggestion in UBL 1.0 FCS?
Without this analysis, I don't think we can do anything but
say "Sorry, too late."
Assignment
We didn't get this far in the call 2003.12.12, but I think
the implicit assignment is to NDRSC to tell us whether there
are the resources available to perform the gap analysis
outlined above.
Outcome (2003.12.19)
I can't find the NDRSC minutes for 12/17.
Further development (2004.01.05)
Mail from Bill Burcham to the NDRSC list indicates that
NDRSC is working on this.
==================================
ISSUES THAT CAN BE CARRIED FORWARD
==================================
2003-1212-03 Schema validation
Issue
We need a clear assignment of responsibility for validating
schemas and example instances using various XSD validators
every time the schemas are modified.
Assignment (2003.12.12)
TTSC to decide which validators shall be considered
authoritative (there should be several) and to fix the
responsibility for (1) running validation checks using these
validators after each build and (2) reporting to the TC that
the build has successfully passed all the checks.
2003-1212-07 Schema generation
Issue
I think this refers to the whole question of who's
responsible for what going into the next build cycle. But I
could be wrong; it's Tim's item.
2003-1212-08 NDR document
Issues
- Publication/feedback schedule
- Effect of changes on Beta -> FCS
2003-1212-09 Beta/FCS diff tracking
Issue
How to maintain and communicate thoroughly detailed diffs of
changes between Beta and FCS for input to the UBL
localization SCs and early implementers
2003-1212-10 Populating the OASIS Registry with UBL artifacts
Issues
- What is needed
- Who can do it
- Deadline 15 January
Background
See the thread beginning at
http://lists.oasis-open.org/archives/ubl-csc/200312/msg00028.html
And further input at
http://lists.oasis-open.org/archives/ubl-csc/200312/msg00055.html
2003-1212-11 UBL compliance
Issue
What does it mean to be "UBL compliant"?
Status
TTSC (which must answer this question for practical reasons)
is beginning to analyze the issue and is in the process of
producing some use cases for further discussion. I have
forwarded their latest thinking on this in separate mail to
the TC list. But the question cuts across CMSC, LCSC, CLSC,
and NDRSC, and therefore its resolution is a coordination
issue.
Background
See the TTSC preliminary analysis of use cases:
http://lists.oasis-open.org/archives/ubl/200312/msg00036.html
And the 1.0 Beta "Guidelines For The Customization of UBL
Schemas":
http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/cm/wd-cmsc-cmguidelines-1.0-beta.html
A paper written by the late Michael Adcock is also felt to
be relevant to this discussion:
http://www.oasis-open.org/apps/org/workgroup/ubl/ubl-lcsc/download.php/4364/Context_NewPaper.doc
2004-0109-01 Code list input from SC4
Issue
At the MoU/MG meeting in Detroit 24-25 November 2003, it was
noted that ISO TC184/SC4 (industrial and product data) has
done a lot of thinking about vocabularies in areas such as
materials handling and process control. We should submit
our code list catalogue to SC4 via the MoU/MG to see whether
SC4 has content to contribute.
Relevant links
www.tc184-sc4.org
www.tc184-sc4.org/About_TC184-SC4/About_SC4_Standards/
The second one gives an overview of the SC4 work.
Responsibility
This appears to be a joint CLSC and LCSC item.
Mark
Mark Crawford
Research Fellow - LMI XML Lead
W3C Advisory Committee, OASIS, RosettaNet Representative
Vice Chair - OASIS UBL TC & Chair Naming and Design Rules Subcommittee
Chair - UN/CEFACT XML Syntax Working Group
Editor - UN/CEFACT Core Components
______
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7481
Wireless (703) 655-4810
mcrawford@lmi.org
<http://www.lmi.org/>
"Opportunity is what you make of it"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]