UBL Naming and Design Rules SC

[ubl-ndrsc] Feedback on code list doc and template: UN/ECE,ebXML Reg/Rep

  • 1.  [ubl-ndrsc] Feedback on code list doc and template: UN/ECE,ebXML Reg/Rep

    Posted 09-27-2002 17:32
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    ubl-ndrsc message

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


    Subject: [ubl-ndrsc] Feedback on code list doc and template: UN/ECE,ebXML Reg/Rep


    I've been communicating further with the UN/ECE folks on whether the 
    code list rules work for them, and have also explored code lists further 
    in the ebXML Reg/Rep context.  I wanted to give a brief summary here, 
    and catalogue some comments that have come in.
    
    - UN/ECE have brought their experimental code list schema modules into 
    compliance with our draft rules.  You can see the results here:
    
    http://www.unece.org/etrades/unedocs/repository/codelistintegration.htm
    http://www.unece.org/etrades/unedocs/repository/codelist.htm
    
    They have a canonical format for the "real" definition of a code list, 
    and a doctored version that meets the needs of UBL and other code list 
    consumers.
    
    - They pointed out the following errors in the rules document and the 
    template, carried over from the position paper days:
    
       . The simpleType should contain a restriction, not an extension, for 
    supplying the enumerations.
    
       . The names of the types should not be QNames.
    
    - They asked whether we have rules for the naming of their types, and I 
    said no, as the names make no difference to our usage of them.  (Does 
    anyone feel differently?)
    
    - Finally, I had a conversation this week with my colleague Farrukh 
    Najmi, who is involved in the ebXML Registry/Repository effort.  I 
    discovered that the Registry Information Model (RIM) spec defines a 
    vocabulary for "classification schemes" (of which country codes and 
    currency codes are examples), and that anyone can use this vocabulary to 
    mark up a canonical version of their code lists.  You can see V2.1 of 
    that spec here:
    
    http://www.oasis-open.org/committees/regrep/documents/2.1/specs/ebrim_v2.1.pdf
    
    They haven't been very active in advertising this model, but even though 
    it's fairly simple I think it's rich enough to accommodate the needs 
    that code list producers have, e.g. to match up code values with names 
    (even multiple versions of names in various languages, so that DE can be 
    associated with both "Germany" and "Deutschland").
    
    The ebXML Reg/Rep project in SourceForge even has some experimental 
    versions of code lists done in this ClassificationScheme vocabulary.  A 
    version of ISO 3166 is here:
    
    http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr/misc/samples/SubmitObjectsRequest_ISO3166.xml
    
    (Note that the author was playing around a bit with the capabilities of 
    the vocabulary, and gave the country codes a little hierarchy -- they 
    know that's not standard.)
    
    I can see where it would be useful to encode the "base/normative" 
    version of a code list as an instance of the ClassificationScheme 
    vocabulary, and then use XSLT to transform automatically -- and possibly 
    even dynamically -- to the schema format required by UBL and other "code 
    list consumers".  What do you all think of this idea?  We would need to 
    make sure that the ClassificationScheme vocabulary has all the right 
    ingredients for such a transform, but it nearly does already...
    
    	Eve
    
    -- 
    Eve Maler                                        +1 781 442 3190
    Sun Microsystems                            cell +1 781 883 5917
    XML Web Services / Industry Initiatives      eve.maler @ sun.com
    
    


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


    Powered by eList eXpress LLC