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

[Anne Hendry <Anne.Hendry@Sun.COM>]

Hi Jon,

I don't quite see what you envision for #2 or #4.  Are you talking about 
all the code lists that are referenced in UBL?

I agree with Tim's statements below, but even more: how can we produce 
enumerations for code lists that haven't been defined other than by a 
name?  I thought we were getting away from providing enumerations in the 
UBL packages - that this is something the user would do when they 
configured their own software.  Many users may already have enumerations 
for these that we couldn't guess at.  It's still my opinion that we're 
best off only including enumerations for the code lists that we own.  
For the others, examples would be the absolute most we'd want to do, but 
even that is a dangerous precedent.  I'd leave that part completely up 
to the users.

-A

Tim McGrath wrote:

> 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
>>  
>>
>