[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Coordination call 9 January 2004
The 9 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. I'm on
vacation this week, so Mark Crawford will be chairing the call.
ADMINISTRIVIA
The only way I can see to solve the time-zone problem is to
hold separate Atlantic and Pacific coordination calls. There
will be an initial one-time Pacific coord call to discuss
localization issues at this time:
17h00 Mon 2004.01.12 in California
09h00 Tue 2004.01.13 in Hong Kong, Beijing, and Perth
10h00 Tue 2004.01.13 in Tokyo and Seoul
We will be using the usual UBL 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
#############################################
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.
=============================================
ISSUES ON THE AGENDA FOR THIS MEETING (01/09)
=============================================
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 judgement 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?
- We need to address the question of conformance testing
criteria.
- CLSC is still debating whether the W3C Schema expressions
should be a normative annex or a sibling chapter to the 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.
- 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 judgements 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]