Re: [codelist] code list validation

["Anthony B. Coates (Miley Watts)" <abcoates@mileywatts.com>]

On Thu, 07 Sep 2006 21:30:22 +0100, Ray Denenberg, Library of Congress  
<rden@loc.gov> wrote:

> You could say:
> <xsd:restriction base="xsd:string" codelist="http://....."/>
>
> There is no such syntax yet (that I'm aware of), most likely because  
> there is no standard codelist format yet. But it might be as simple as  
> above --
> defining a 'codelist' attribute on the restriction element within the  
> schema language. Of course it would need to be accepted into the  
> language by the
> W3C.

There are a couple of issues here that I want to mention.  Assuming that  
the TC takes genericode as its starting point, genericode supports (a)  
multiple keys for a code list, and (b) compound keys for a code list.  So  
there is no automatic way you can point to a code list definition and  
extract "the" set of codes.  Now, I expect 80% of code lists to only have  
a single simple (non-compound) key, so in many cases it could work, but it  
wouldn't work 100% of the time.  There would need to be a plan to cover  
the inevitable failures when it didn't work.

On a more philosophical level, one of the intentions of genericode was to  
define a format for code lists that wasn't tied to any particular  
implementation of a code list validation engine.  This differs from the  
philosophy of things like W3C XML Schema; I usually characterise it as a  
control language for XML validation engines, and not as a modelling  
language.  When you try and tie something too directly to the engines that  
implement it, you are forced to take implementation issues back into the  
format, and that makes it less generic.

I would like to see the TC produce a code list format that can be applied  
equally to Schemas, Java/C#/etc., databases, i.e. everything.  That  
requires a certain standoffishness in terms of not getting too closely  
tied to way any particular methods that these technologies might use for  
implementing code list validation.

My preferred approach would be for us to look at producing some reference  
tools for generating Schemas, Java enumeration classes, database tables,  
etc. from our code list representation format.  For example, for Schemas,  
a simple XSLT stylesheet could do the job for most cases, and it could  
generate a warning for cases that it couldn't handle.  The same could be  
done one way or another for the other targets too.

If groups like the W3C *want* to try and build direct support into their  
works, I wouldn't try to stop them, but I would be very cautious if  
implementers were pushing back for features that were only required to  
support implementation, and not required for the generic representation of  
code lists.  In a similar vein, I wouldn't be inclined to start opening  
discussions with the W3C until we at least a reference Schema generation  
solution in place, just so we don't start the external discussions before  
we have sufficient maturity in what we are doing.  Whenever you get into  
these external discussions, the external parties always ask you if you can  
do new things, and do them their way.  If you don't have sufficient  
maturity, you can end up agreeing to things that have a negative impact in  
the long run.  I suggest we make sure we are all happy ourselves before  
kicking off any outreach stuff.

How does that sound?

Cheers, Tony.

PS  If the W3C were to implement some kind of direct support for  
genericode-style codelists, I think it would be better done using a  
"key/keyref" style mechanism, rather than an "enumeration" style  
mechanism, but there would still be many questions to resolve.  I just  
can't see it happening until such time as the Code List Representation  
format has some marketshare and mindshare to speak of.
-- 
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
+44 (79) 0543 9026
Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312,  
UN/CEFACT TMG, MDDL, FpML, UBL.