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] Re: [ubl] CLSC: Minutes 19 November 2003


I browsed the paper "wd-ublndrsc-codelist-05_las_20030702.doc"
titled "Universal Business Language (UBL) Code List Rules
Working Draft 05, 9 June 2003".  I don't know if I'm the only
one being confused with the purpose and content, or that I'm
speaking for others, but I'll go ahead and voice out anyway.

(1) First of all, calling the paper "Code List Rules" is not appropriate,
given the current contents of the paper.

In Section "1 Introduction", it mentions "Section 3 provides
non-normative recommention to use ebXML Registry ClassificationScheme
XML Schema as a schema for representing UBL Code lists".
The sentence can be misleading, in the sense that there is some
preconceived "recommended" manner of constructing code list
schema in the minds of the editors.  The paper is *supposed*
to let reader know definitively how to do code list schemas 
in UBL when the paper is completed, not really to suggest
pointers to recommendations (even though qualified as non-normative
recommendation, it is still a recommendation).

The *actual* Chapter 3, down at about page 16, however, is about
"Conformance to UBL Code Lists", a subject that is very near
the scope of being normative than non-normative.


(2) Second, Section 4 presents an interesting selected survey of
how to implement code lists in different ways.  It represents
a nice extent of thoughts, but does not fall into a paper that
calls itself "Code List Rules".  The entire reasoning, assessment,
etc should be pulled out and put into another survey paper of
some sort.  That would record the efforts, but not waste 
implementators' time to re-live the schema form selection process.


(3) Third, whether we call it "Code List Rules" or "Code List 
Implementation Specification" or some other names, the purpose
of the outcome should be to give implementors very specific
instructions, the dos-and-donts, with regards to how given a set
of code values, be they specified externally or generated internally
from within UBL, a corresponding schema could be *unambiguously*
constructed based on those values.


(4) Fourth, the paper rightly pointed out the difference between 
a simpleType code value type, and a complexType code list type.
However, much, in fact, too much, of the content was spent on
talking about the latter when it is actually the former (the
simpleType) that is of much importance.  The relationship of
namespace value definitions between the simpleType code value
type and the (corresponding) complexType of the code list
in which a code value is in isn't that clear, or needs further
explanation.  


(5) Fifth, to measure "ambiguity", the paper needs to look at
and define code list equivalence.  Much like sets, the paper 
needs to lay the ground rules of:
  - what is a null code list (or is it permitted),

  - what is a unity code list (or does it not make sense), 

  - what is the equivalence operator (roughly speaking,
    two code lists are defined as "equal" when each code point of 
    one list matches exactly one code point in another),

  - when is a code list unique (is it that it isn't a uniquely
    different code list whenever there is a "standard" code list
    that is "equal" (based on definition above) to it?)

THEN,

(6) Sixth, the paper can talk about union and subsets.





Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Thu, 20 Nov 2003, Mavis Cournane wrote:

>>Dear members of the CLSC
>>attached are the minutes of the CLSC meeting on 19 November. The general UBL
>>mailing list will be used to conduct business until the CLSC mailing list has
>>been set up.
>>
>>Regards
>>Mavis Cournane (Co-chair)
>>Cognitran Ltd
>>
>>
>>Roll Call
>>Anne Hendry (AH) (voting)
>>Mavis Cournane (MHC) (voting)
>>Ken Holman (KH) (voting)
>>Marty Burns (MB) (prospective)
>>Arofan Gregory (AG) (prospective)
>>
>>Regrets
>>Sue Probert
>>Tony Coates
>>
>>AWOL
>>Gunther Stuhec
>>Chee Kai Chin
>>
>>1. Review of Agenda and welcome by the co-chairs (Mavis Cournane, Ken
>>Holman, Sue Probert).
>>
>>
>>
>>Initially we will have a call every week to get the work underway.
>>The calls will be scheduled  for 2 hours at this time 10:30-12:30 PST
>>
>>AG: There is some disagreement if we need to finish the position paper first.
>>MHC: The controlled copy will be PDF. We will be working from the June position
>>paper.
>>We have two inputs to the NDR position paper - Gunther's submission and the
>>NIST submission.
>>KH: I would like to see about making the changes in the model rather than the
>>instance.
>>
>>AG: This groups will be synthesis
>>MB: My impression is that each submission presents a different aspect of the
>>core.
>>Use cases will be very important for evaluating different proposals.
>>
>>AG: All the propsals will work mechanistically. You are going to put complexity
>>on the contract between trading papers,
>>or you deal with the complexity in the XML. We have to make a decision of where
>>we put the complexity.
>>
>>
>>AH: It is interesting you are raising who our target audience is. This will be
>>discussed in the implementation SC.
>>One of the criteria for implementation is which market segment will the TC want
>>to focus on.
>>
>>2. Review of Charter and membership
>>
>>
>>The following members are eligible for the following status:
>>Mavis Cournane (voting)
>>Sue Probert (voting)
>>Ken Holman (voting)
>>Arofan Gregory (prospective)
>>Anne Hendry (voting)
>>Gunther Stuhec (voting)
>>Tony Coates (voting)
>>Chee Kai-Chin (voting)
>>Marty Burns (prospective)
>>
>>Action:
>>MHC will check with Jon Bosak if Marty needs to be a voting member of the TC
>>first before he can be a voting
>>member of the SC.
>>
>>MHC will check with Guther, Tony and Chee Kai and see if they intend to be
>>voting members.
>>
>>
>>For now we will be using ubl list until the CLSC mailing list is sorted out.
>>People should prefix any postings to the general UBL with CLSC
>>for now to help with sorting.
>>
>>3. Agreement of Timescales and Strategy
>>
>>We have three months to do what has asked of us in the plenary in San Francisco:
>>The tasks are:
>>1. Complete the Code List position paper taking in to account the input
>>received and publish it as a TC Draft
>>2. Define a standard schema template for code lists based on existing NDR
>>specifications
>>3. Work with NDR on any changes
>>4. Work with LCSC to create "standard" and "stock" code lists for inclusion
>>with UBL 1.0 FCS.
>>5. Define a maintenance and versioning strategy for the code lists included in
>>UBL
>>
>>
>>MHC: I propose that we will begin with looking at the June 9th Code List
>>position paper (v5) sent out by me to the UBL list.
>>
>>We will then look at the inputs to it. There are 4 inputs we will look at:
>>- Gunther's input to the June 9th paper (v5)
>>- The Montreal Methodology (Ken will provide the link for Mavis to send out)
>>- EBSC Memo (Marty to provide Mavis with the link to send out)
>>- EBSC input to version 4 of the NDR code list position paper.
>>
>>MHC: Next we will look specifically at the June 9th Code List position paper
>>and determine what the issues are with it.
>>Homework for everybody next week will be to have studied this and be prepared
>>for the walk through.
>>Who will volunteer to conduct the walk through?
>>
>>AG: Mavis I am happy to do this.
>>
>>MHC: Ok, so next week Arofan will walk us through the document. THis will be
>>the core from which we will direct our efforts.
>>We will then look at the other inputs. Which input will we start with?
>>
>>KH: I think that Gunther's paper is the next logical ste.
>>
>>MHC: Are we agreed. Following this then we will look at the other inputs as
>>well to make sure we understand all
>>the issues and approaches open to us. Do we have any issues that we know about
>>so far?
>>
>>KH: The instance or model approach is an issue wit the June paper. Mechanically
>>both work, so we need to recommend an approach.
>>
>>MHC: We will need to liaise with NDR and LCSC every step of the way on this to
>>ensure that all parties are
>>in alignment. I will understake to give a weekly CLSC report on the NDR call.
>>AH: Sue or myself will do the same for LCSC.
>>
>>MHC: We will ensure that the code list TC spec and the relevant NDR section
>>will be aligned.
>>
>>AH: In terms of things to reviewing shouldn't we be reviewing NDR Document Code
>>List Section
>>MHC: I have done some editing of the section, but much of it is waiting input
>>from us.
>>AG: Our solution has to be expressed in a normative way. Section 6 of NDR will
>>not be simple to write.
>>
>>MHC: We need to agree an approach for editing the position paper and the
>>ensuing TC draft. This time round
>>I propose we have a lead editor and an editorial panel
>>Agreed: Arofan will be the initial lead editor, the editiorial panel will
>>comprise of Ken, Marty.
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>>
>>




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