Code list packaging for UBL 2.0 was: genericode & XSD (genericode-and-xsd.zzz)uploaded

[Tim McGrath <tmcgrath@portcomm.com.au>]

sounds like a good idea to me.  i think we didn't produce class 2 codes 
because we didn't want to  - but i guess we could provide examples.

the critical thing here is item (1.) - we want to encourage validation 
of these.  the rest is packaging.

jon.bosak@sun.com wrote:

>[abcoates@londonmarketsystems.com:]
>
>| > Is it our intention to provide XML code list formats for the current UBL  
>| > 1.0 code lists?
>| 
>| Good question.  I hadn't thought about it.  From my point of view,
>| I would be happy enough to support both the 1.0 and 2.0 code
>| lists, if people thought it was worthwhile to do so.
>
>Here's the ideal setup for the user:
>
>   1. All of our class 1 code lists in UBL 1.0 enum format
>
>   2. All of the class 2 code lists referenced in UBL documents in
>      the new generic code instance format (I don't think we ever
>      did provide all of these, did we?)
>
>   3. A script that produces enum format from instance format
>
>   4. Generated enum versions of all the class 2 code lists using
>      the script in #3
>
>   5. An out-of-the-box first pass validation driver that
>      validates any instance against all of the code lists in enum
>      format
>
>   6. A script that produces SCH from instance format
>
>   7. Generated SCH versions of all the class 2 code lists using
>      the script in #6
>
>   8. Generated .xsl files for each of the SCH files in #7
>
>   9. An out-of-the-box two-stage validation driver that validates
>      any instance against all of the code lists
>
>   10. A sample out-of-the-box two-stage validation that
>      illustrates how this approach supports the implementation of
>      business rules in the second validation pass
>
>The question is how close we can come to this and still meet our
>deadlines.  Looks to me like we have to work out an added row in
>the schedule and see how this fits.
>
>Jon
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476