more on code lists was: Re: [ubl] Minutes of Atlantic UBL TC call7 June 2006

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

jon.bosak@sun.com wrote:

>   Code list enums
>
>      JB: We will have to discuss this later, then.  I thought the
>      plan was to provide scripts so that users could generate
>      equivalent (but non-normative) schemas in which all of our
>      default code list values were embedded as enums so that they
>      could just use XSD validation as in 1.0.
>
>      SW: CCTS compliance is the big issue : if you have enums
>      (QDTs) they must be based on UDTs.
>
>      MG: I.e., they should all be restrictions of code type.
>
>  
>
i may be missing something but i don't think this is the problem here.  
yes we could provide scripts that show equivalent (but non-normative) 
schemas that are restrictions of uDT CodeTypes, but there is nothing in 
CCTS about enumerations of code lists being based on uDTs.  it says qDTs 
should be based on uDTs.  so we will have a ChannelCodeType based on a 
CodeType, but the qDT need not (in fact, cannot) say anything about the 
possible values for the content of ChannelCodeType (except their 
location).  i tried to demonstrate this in the examples i created yesterday.

indeed, this is what we did for UBL 1.0 - the actual schemas for the 
code list values were our own invention, pointed to by the qDT (or sDT 
as it was then). 

what we are doing with the genericode approach is replacing an XML 
schema for enumerated code list values with an XML document instance for 
code list values.  this leaves the implementor to determine their own 
validation techniques.  one of these could be using a script to create a 
schema from this genericode document (perhaps using marty's schema 
model) and validating document instances against that.  the key point is 
that this is second pass validation - not normative UBL validation.  as 
Jon says, our NDRs need not apply to this - but if we provide a sample 
script, this example should try to.

>      PB: I question the allocation of code lists to QDT and UDT
>      in the current spreadsheets. QDT is not used for any but the
>      ATG1 lists.
>  
>
maybe a misprint but this appears to be incorrect.  i presume ATG1 means 
ATG2 but either way we dont use qDT for these.  we should be using qDT 
for the non-ATG2 code lists.

this is why we need them in spreadsheets - so we can determine the 
metadata that is used for these code lists.


-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath