OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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 
ubl-clsc@lists.oasis-open.org. 

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. 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]