Re: [codelist-comment] The basic structure of the lists

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

[This is a personal reply, not an official reply of the Code List  
Representation TC.]

Dear Martin,

On Fri, 18 May 2007 11:24:04 +0100, <martin.me.roberts@bt.com> wrote:

>   As a person who would need to convert the lists to be used by other
> applications, I have some concerns over the structure of the lists in
> terms of the XML.
>
>   In order to get values from any list the xpath required would need to
> be complex in terms of looking for an appropriate attribute that given
> that name of the value and then fetching the value from a related
> element.

Genericode is intended as an interchange format for code list data and  
metadata, and is not optimised for run-time lookup of codes.  I fully  
expect people to process genericode documents to produce data that is in a  
form that *is* suitable for run-time lookup of codes, rather than to do  
run-time lookups from genericode documents directly.

>   This gives you a flexible structure for defining data but it does not
> allow schemas to provide validation of content or for applications to
> easily pickout the required data.
>
>   I would have prefered the use of something like
>
>   <Value>
>     <numericode>1</numericode>
>   </Value>
>
>   Rather than
>
>   <Value type="numericode">1</Value>  (yes I know this is not an exact
> example from the document)
>
>
>   The later form would not be able to be validated by a schema and
> therefore it would be possible to have the word numericode spelt
> incorrectly and the list would be broken.  There are tools which can
> help in this kind of thing (CAM, Schematron) but it would be better to
> have a structure that made the best use of native XML rather than this
> current open schema approach.

I can only stress that genericode may not seem ideally designed, of  
course, for things that it indeed wasn't designed for.  Genericode does  
not assume that the data type system in use is always the XML Schema data  
type system, which is why it doesn't use the kind of structure that you  
suggest.

For many simpler uses of genericode, you could use an XSLT stylesheet to  
process the genericode to produce a document whose code and metadata  
values can be validated using an XML Schema.  Alternatively, you could  
enhance a genericode document with user metadata (using the "Annotation"  
element)to add directly validatable equivalents of the codes and metadata  
(in elements in a separate namespace) that could be validated using a  
separate XML Schema.

>   One was round the need to allow flexibility of the names for value
> types would be to have a schema structure that others could use to
> define elements that could become legitimate children of the value or
> row structures.

I'm sorry, I don't understand sufficiently well what you are getting at  
with this last paragraph.

Genericode will require some of its own software tools, that is true.   
Miley Watts LLP is looking at producing an open-source application that  
validates genericode documents and the values in them, for example (i.e.  
the tool would check the genericode documents themselves, not other  
documents that use the codes from the genericode documents).  While it  
would have been possible to produce a spec that only has features that can  
be easily supported with existing tools, that would not have allowed the  
production of a spec that is sufficiently broad and flexible in what it  
can represent (in my opinion).

Cheers, Tony.
-- 
Anthony B. Coates
Senior Partner
Miley Watts LLP
Experts In Data
+44 (79) 0543 9026
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),  
UN/CEFACT, MDDL, FpML, UBL.
http://www.mileywatts.com/