[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [codelist-comment] The basic structure of the lists
[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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]