Re: [codelist] Re: Updated genericode specification

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

Comments below.

On Mon, 03 Sep 2007 18:48:12 +0100, G. Ken Holman  
<gkholman@CraneSoftwrights.com> wrote:

> (1) - is it appropriate to include "must not be used as a de facto  
> location URI" statements?  Is that not out-of-band of the specification?

I don't think it is out-of-band.  The point of conformance clauses is to  
make sure that application behaviour is predictable and consistent and not  
dependent on individual interpretations of a specification.  (1) is  
important because the interpretation of a genericode code list could  
differ in two applications if they use the various URIs differently.  When  
I originally wrote my genericode draft, I was seeking to explicitly to  
avoid doing the same as W3C XML Schema, which has oft been criticised for  
its use of namespace URIs as de facto Schema lookup URIs.

> (2) - "xml:base does not apply to canonical URIs" seems related to use,  
> not specification

Same as (1).  This is what conformance is all about, making sure the  
information is interpreted the same way by different applications.

> (3) - if we are to include "An application must ..." statements (I'm not  
> sure we should) then the opening paragraph of 4.4 needs to be augmented  
> with something like:  "including the following auxiliary rules imposed  
> on a genericode instance or an application processing a genericode  
> instance:"
>
> The reason I'm hesitant about "An application must..." statement is that  
> we aren't defining a specification like XSLT with a processor, we are  
> defining a data format.  Is it up to the specification to impose such  
> constraints on how the data is used?

We aren't constraining how it is used, rather how it is interpreted.  It's  
all about ensuring that the details of a code list are never ambiguous,  
that the values don't depend on which application you are using to  
interpret the code list.  It's not telling the application how to use the  
information, just how to interpret it consistently and correctly.

> (4) - perhaps change "The external reference must not be prefixed with a  
> '#' symbol." to "The external reference must not begin with a '#'  
> character." since the reference is not separate from the prefix (and I  
> think "character" is more appropriate than "symbol")

OK.

> For example, if the file at a LocationURI changes arbitrarily, that  
> changes the conformance of a given genericode instance according to this  
> conformance clause.  I think it is enough *for conformance* that the  
> LocationURI be correctly formed regardless of what it points to.  What  
> if, say, the user is acting locally without an Internet connection ...  
> the content at the external location is unknown ... does this mean the  
> conformance of his instance is unknown?

There needs to be consideration of what happens for an offline machine,  
which may not be able to retrieve some location URIs, but should still  
work through the list looking for a local URI that it can resolve.  It is  
important that we discuss what should be expected to be retrieved from  
location URIs, since the interpretation of a code list depends critically  
on any external column sets or code lists that it refers to.

> So does it make sense to only include in the conformance section clauses  
> that apply to the instance as a standalone artefact, and move other  
> issues to a "guidelines for applications" section and make it  
> non-normative?

No, because the things I've outlined are necessary for conformance in the  
sense of consistent interpretation of code lists in genericode format.

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