[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]