[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ciq] Use of OASIS code list specs. in CIQ TC V3.0?
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.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]