[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CLSC: Minutes December 3 2003
Dear all the UBL CLSC list is now up and running. In future I will not be sending mails to this list that pertain to CLSC business, so please enroll now on email@example.com. Additionally, if you are a member of CLSC and cannot make next week's meeting on Wed Dec 10th at 10:30am PST please send me regrets. The agenda for this meeting will be sent to the clsc list and is available from the CLSC portal page. http://www.oasis-open.org/apps/org/workgroup/ubl-clsc/ Regards Mavis ------------------------------------------------------------- Roll Call Tony Coates Frank Yang Alan Sitzer Marty Burns Ken Holman Anne Hendry Mavis Cournane Arofan Gregory Regrets Sue Probert Chee Kai Chin 1. Welcome from the chairs (Ken, Mavis) When we have the portal we will handle the membership issues. 2. Tony Coate's submissions with regard to our charter MB: The idea to separate the data model form the schema implementation is a good one, although in my work I found it was hard to separate the two. It is a clean break really? The consequences of the schema rules make it difficult. AG: I think we need to do the following: 1. There is a data model 2. An implementation of that data model in schema 3. Whatever NDR has to do to align with that implementation. KH: My understanding is that we have to consider those not using W3C schema. AG: We can produce a clean data model. we can do both in a separate deliverable. KH: If we come up with a schema fragment as part of this groups work, does this get used by UBL. Is it an abstraction. AG: No it is a functioning schema module. We are going to produce the schema. TC: I think we would just produce the Data Model and an XSLT transform that is compatible with the NDR Rules. AG: You are missing a key piece. A set of data for describing code lists i.e our model, LC don't use that model, they take the schema fragments and populate it. MHC: I think that roughly speaking for now we can say that CLSC have the following goals: 1. Create the Data Model for the code lists. There will be a schema to describe the data model. Any code list is encoded as an instance 2. Provide a schema that is compatible with the NDR Rules. This schema fragment will be populated by LC. TC: I suggest lets not just publish a standard schema. Let's publish a data model in XML, let's implemnt it as a standalone standard for UBL, that gets used for NDR. MHC: We will come back to this but for now let's go through the NDR Position Paper v5 on Code Lists. Arofan will take us through the main points. AG: In looking at this document (NDR position paper), there is a high similarity of intent with the document that came out of Montreal and the use cases are also similar. However it is very technically different. One of the things all of these appraoches have recommended is the placebo approach. There is a second approcah, people do want to create enumerations that will validate whether a code in a document is legitimate or not. This has been agreed on essentially by everybody. People in UBL will need to create these for UBL in some cases, but the people using these documents will need to decide the values an attach their data types to UBL. We may have this idea of a required UBL code list that is part of the library and has to be used. There is further a requirement for the provision of default values. THis is not in every approach, but was not very explicit in the NDR paper. AH: In LC default value was the solution to the requirement, but the real requirement is the out of the box solution. TC: I am building a UML model a model of a code list, and a model of a code list schema. There will be particular of the parameters of the schema generation, and that is not part of the code model necessarilyu. AG: You have a conceptual and an implementation model. AG: Section 2.1 makes a distinction between first and second order codes. We might want to agree to adopt this terminology. TC: The first and second order is part of the code list schema. MB: The second order is an attribute, and first order is an element. What is the purpose of recognizing the difference. AG: A simple type can be used in a an attribute and an element. It is a semantic difference. If I send you a product code that tells you what product I am giving, is a first order, if I send you an address, that is more meta information. These are ebXML names. AG: 2.2.3 these are more requirements. This is expressed in terms of the ebXML Core Components model. THis gives you an idea of the scope. AH: Are there any implementations of the CCTS code list stuff? AG: Yes there are a few e.g. Swift etc. They directly comply with the data points that are represented here. In the schema we have a complex type that is a description of the simple type In the example we don't have the technique used to bind the external list . What you see here is the placebo schema. L338 - we will need to update the example if we want to use that approach. L384 - we see a complex type, both of these are owned by external organisations. What we get in to here is a complext type that carries all of the meta data in the CCTS and binds it to the structure. The reason this was done, was not just to reflect CCTS but to provide an element that could be added as an extension. This approach aligns with the UBL customisation approach. This is a way of binding an external code list validation to the UBL library. How to derive new code lists from old ones. THis is one issue we will have to resolve. NDR proposes the use of Union Types. Section 4 covers technical requirements not business requirements. MHC: Ok, so we have gone through this paper. I think we need to start pulling out the requirements in to running list so that when we go through the other submissions we can add to this list. Marty, can you perhaps undertake to pull out the requirements in this document? MB: Agreed. MHC: We don't seem to have any contribution from Gunther on these calls. I will mail him and ask him if he wants his submission to be considered. If so we will need him to take us through it. We will need to check if next we have enough people on the call to warrant having it. The XML conference could mean that we have such low attendance we won't have enough mass to get anything done. Arofan, and Tony send regrets for next week. Next week, Marty will take us through his submission, we will review the requirements he listed. Adjourn.