Re: [ubl-ndrsc] Minutes February 12 2003

["Eve L. Maler" <eve.maler@sun.com>]

Responses back to Mark:

CRAWFORD, Mark wrote:
> Eve wrote -  
> 
>>I think what would be most productive is to start with the 
>>UN/ECE code list schema modules and try to work with them to get them into 
>>compliance (but notice that we need to modify our own rules 
>>to get them, in turn, into CCTS 1.90 compliance first!).  But if the UN/ECE folks 
>>aren't interested or don't have time right now, then I think it's fair 
>>to mock up "country code" and "currency code" modules based 
>>on theirs, but eliding or perhaps faking most of the real content.
> 
> 
> I agree, however it would be beneficial if Eve could identify which of our rules she believes are not in compliance with CCTS 1.9.

This is one of the areas I've already discussed with Lisa.  Basically, 
our published rules use CCTS 1.8, which had many fewer supplementary 
components for codes than 1.90 does.  Gunther's work on the CCT position 
paper has most of what I think we need for an update, and I suggested to 
Lisa that she transplant quite a lot of Gunther's tabular and 
non-tabular material around these supplementary components into the code 
list rules document.

> .
> 
> Mavis wrote -  
> 
>>>There was a discussion on enumeration as per our code list proposal. This
>>>works largely for fairly static code lists. David Webber rightly points out
>>>that for very dynamic code lists like HL7 XML schema is not very useful as is
>>>the case with static ones.
>>>Jessica's group have also difficulties accepting the enumerated list part of
>>>our proposal.
>>>Arofan suggested that we should bring Tony Coates from TC154 who wrote Best
>>>Practice on Enumeration more in to our loop.
> 
> 
> And Eve wrote -  
> 
>>To be clear, our rules do not mandate or even recommend enumeration. 
>>The amount and type of constraints put on the code values is 
>>entirely up to the code list producer.
> 
> 
> I am not sure I completely understand or agree with this.  I thought our whole purpose was to get us out of the business of duplicating code lists through enumeration while maintaining the ability to do server validation of the codes.  Eve's solution was a way that other standards bodies would publish their code lists in an accessible fashion, we would import them on demand rather than enumerate them ourselves, and thus preserve runtime server validation without having to maintain duplicates of the code lists.  As such, we absolutely need enumerated lists, and it is inconsequential to us if the list is dynamic or static. In fact, a dynamic list seems even better suited to this than a static one.  I fail to see how pattern matching offers any value in addressing this problem, as we can simply define the pattern ourselves from a quick analysis of existing code lists. 

UN/ECE's exploratory schema modules in this area happen to use 
enumeration for county and currency codes, and I personally feel that 
enumeration should be used whenever possible because it's a "tight" set 
of constraints.  But sometimes it won't be possible, e.g., when the list 
of codes is impractically long or when the code values are more 
recognizable as being in a certain pattern than as being in a certain 
set (though admittedly these latter types are likelier to be identifiers 
than codes!).

	Eve
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com