Fwd: Re: [ubl-ndrsc] New version of code list position paper

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

I got Phil's permission to forward this; he's at the RSA conference this 
week with little time to follow up further.  I have also added some of my 
own comments below.

>Date: Wed, 20 Feb 2002 18:38:32 -0500
>From: Phil Griffin <phil.griffin@asn-1.com>
>Organization: Griffin Consulting - http://ASN-1.com
>To: "Eve L. Maler" <eve.maler@sun.com>
>Subject: Re: [ubl-ndrsc] New version of code list position paper
>
>Eve,
>
>Very nice work. And I agree with your option
>one preference in section 3.4.3.
>
>I have a comment/question on section 4.1,
>'need to "union" multiple existing external
>code lists' related to the issues stated in
>section 3.3.
>
>In my mind it would be natural to allow a UBL
>user to select by reference more than one code
>list and create a set, the union of all such
>lists. It would not seem unreasonable for the
>user to also want to add by value other specific
>codes to this set in order to form a complete
>custom set of codes.
>
>[It is a frequent occurrence in ASN.1 specifications
>to see this, what we refer to as information object
>sets. These sets are used to constrain the values
>that are valid for a given instance of a value of
>some type. Each set can be composed of sets that
>are "unioned" along with individual objects that
>may not appear in any given set. These IOSets can
>be made extensible to allow for versioning and
>unexpected values, and the set of objects can
>change dynamically at runtime.]
>
>So, it is this concept of set building that I'm
>attracted to. And I understand that whatever is
>the final mechanism provided will fall to the
>CM group. But I wonder if section 3.3 might
>benefit from being broadened a bit to suggest
>such possibilities as noted above.
>
>Phil

If we want to allow extension designers to create custom code lists by 
listing several external code lists (plus possibly enumerating additional 
codes "by value"), we'll have an interesting problem in that codes from 
different code lists might clash.  It's basically the XML namespaces 
problem...  It might in that case make sense to go with the "namespace 
prefix" option for all/most code usage, just to save our sanity!

By the way, I realized after I sent out codelists-03 that the identifier 
mechanism I propose for UBL-internal code lists (UBL-URI#identifier) 
wouldn't actually work with the option for making custom codes *be* URIs, 
because the former identifies the code list (and has no way to identify a 
specific code from the list), whereas the latter requires the 
identification of a single code by means of a URI.  Sigh.  Back to the 
drawing board, for *something*...

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com