RE: [ciq] Use of OASIS code list specs. in CIQ TC V3.0?

["David RR Webber \(XML\)" <david@drrw.info>]

Ram,

 

OK - I'm with Ken on this one!

 

Having it all in the one schema is a bad idea.  You need to be able to versioning and do subsetting based on context.

 

And so the two stage approach is the right one IMHO.

 

Notice - I'm also following his genericode approach with CAM.   I run an xslt against his genericode list (.gc) - to produce the CAM sparse lookup codelist.xml - to get best performance / context at runtime. 

 

So - what Ken is saying is point to the schema for the codelist - and not import it in CIQ - because its not designed for that anyway.  If you did import it into schema - it would have to be as a tokenized list of values. 

 

Notice that approach fails for cross-codelist lookups - e.g. if countrycode = "UK" then currencycodes="[list1]" - or more likely - if countrytypecode ="EU" then currencycodes - "[list2]" - where the values of one list - down select against the other list.

 

More reasons to do a 2 stage pass - otherwise you get caught - where the schema either allows content thru as valid that is not - or gives an error when its OK.

 

Also - what about multiple encodings?  Often the list changes - e.g. if 'US' - allow imperial - else use metric codes.

 

And this is what the W3C is enabling anyway - simple tokenized lists is OK for boolean or short static choices - otherwise - you should supplement the XSD with tools like CAM and schematron.

 

Errrh - where does this leave you?  UBL already have the genericode approach - so they will use that with CIQ. 

 

Are there other customers we need to provide for right now - or do we wait until someone has a use case for us?

 

DW

"The way to be is to do" - Confucius (551-472 B.C.)