OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

codelist-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [codelist-comment] Relationship with ISO 11179

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

Dear Peter,

> The model and approach used seems to be an implementation of Parts 1 and
> 2 of ISO 11179, and yet no mention is made in the draft recommendation
> of this provenance.

Really?  I don't see an obvious connection between the two, not myself.

> -          if it is intended to be an implementation of ISO 11179 Parts
> 1 and 2, why is no mention made? Could you point to how and where the
> specification coincides with or differs from the ISO standard?

It is not an implementation of ISO 11179.

> -          if it is not intended to implement or leverage ISO 11179, was
> this standard at least examined in the course of the TC's work? what
> were the reasons for not explicitly working with it?

Speaking for myself, I don't find ISO 11179 particular interesting as a  
format for code lists.  It is interesting as a general data and metadata  
format, and I am involved with a number of standards (UN/CEFACT CCTS and  
ISO 20022) that make use of ISO 11179 concepts.  ISO 11179 can be applied  
to many data representation situations, and as such you can apply to  
representing code lists, but I don't think that is any more helpful than  
saying that you can use an XML Schema to represent an enumeration even if  
you don't plan to use it for validation.  While you can press many formats  
into service for representing your code lists, I think there is a need for  
a code list format that is only designed to represent code lists, and not  
more general data/metadata.

A reason that XML Schemas enumerations aren't seen as a good way to encode  
code lists is because, if you receive an XML Schema, there could be any  
amount of non-code-list data structures in it, and that forces you to  
check whether what you have received is just code list information or  
not.  The same principle applies to any format that allows for more  
complex data structures than are needed for code lists.  I hope that  
illustrates the point I'm trying to make here, at least in part.

Perhaps I should also mention that genericode is also not intended to  
compete with RDF/OWL (or ISO Topic Maps), so its design is focussed on the  
needs of users of flat code lists, not on the needs of users of  
hierarchical taxonomies and ontologies.

> Our primary concern is to establish what the advantages and issues would
> be for an implementer to use the proposed specification rather than ISO
> 11179 and/or - if  they are not orthogonal - what the relationships
> between them are.

Genericode is intended as an interchange format for code lists  
specifically, and I would hope that people will use the information to  

* XML Schema enumerations;
* programming language enumerations classes (e.g. Java/C#);
* database code tables;
* metadata repositories, such as ebRIM repositories (which are based on  
ISO 11179);
* any other systems they use for run-time code list checking.

These are important targets, let me be clear about that.  Genericode isn't  
about replacing any of them, only about helping to populate and  
synchronise them.

I hope that helps in positioning genericode.

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),  

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]