Re: [codelist] Re: Updated genericode specification

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2007-09-03 22:09 +0100, Anthony B. Coates (Miley Watts) wrote:
>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.

Here is what we are beholden to according to the process document:
   http://www.oasis-open.org/committees/process.php#transition_2_18

"A specification that is approved by the TC at the Public Review 
Draft, Committee Specification or OASIS Standard level must include a 
separate section, listing a set of numbered conformance clauses, to 
which any implementation of the specification must adhere in order to 
claim conformance to the specification (or any optional portion thereof)."

The "implementation" to me is the bits and bytes of the file 
format.  I claim a particular file I've created conforms to 
genericode.  The specification describes the properties of the 
file.  If I create a set of genericode 1.0 files for UBL I have no 
thoughts about the applications acting on those files, I am merely 
ensuring the bits and bytes in the file conform to the specification.

Looking at page 56 of the August 28, 2007 draft, looking at the third 
context (BTW, these need to be numbered according to the text above), I read:

         An application must signal an error to the user if it is
         not able to retrieve a code list document to match the
         code list reference.

My suggestion in the meeting was to turn this same conformance 
requirement around to focus on the file format and not the 
application, using wording along the lines of the following:

         A genericode file code list reference points to a
         conformant genericode code list document.

As Jon pointed out, this is more declarative than procedural.  It is 
stating what constitutes the conformance of an instance of 
genericode.  An application can then decide what to do if it is 
dealing with an instance that is not conformant:  it can just stop, 
it can report an error, it can do some fallback behaviour with other 
files .... we are not obligating the application "must signal an 
error to the user" because what if it doesn't want to but wants to do 
some other behaviour because the file is not a conforming genericode file?

>>(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.

I disagree.  I think that is what the specification is about.  I 
think conformance is a check list of the specification but does not 
replace the specification or add anything new.  It could even cite 
chapter and verse so that someone reading the conformance clause can 
go and get more information.  Looking for chapter and verse for 
xml:base I see on page 29 the same wording you have above.  If this 
is important to bring out in conformance, then a conformance clause 
might read "all canonical URIs have not incorporated xml:base" or 
some such in order to focus on the canonical URIs themselves.

For another example, looking at my suggested rewording above, section 
3.5 on page 23 states "Each of these [CodeListRef elements] is a 
reference to a code list or to a version of a code list".  That is 
the specification requirement against which conformance is measured 
... I don't think we have to say anything about application 
behaviours.  My wording above covers the specification statement.

I now acknowledge the recently added text to the genericode 
specification has application behaviours (I just found them doing a 
search) that are echoed in the conformance clause.  I had missed 
this.  I am of the opinion it doesn't belong.

>>(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.

Then let's state it in terms of the genericode file as to what has to 
be true *about the file* that it will be unambiguously interpreted 
consistently and correctly.

>>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.

Then the specification can state what the interpretation of a 
genericode file is in the presence and absence of a resolved URI reference.

Looking at it from the perspective of a user of genericode:  how I 
can commit to the UBL TC that the genericode files I create for them 
all conform to the genericode specification if it is up to an 
application acting on it to measure conformance in real time?  Say I 
have a code list reference to an artefact sitting on the OASIS 
server.  The genericode file is a conforming genericode file because 
the artefact at the URI reference is valid.  If the artefact were 
absent, then it isn't.  I can accept that.  But if an application 
acting on the genericode file happens not to be able to access the 
artefact that does exist, does that make my genericode file 
non-conformant?  I don't think it does.

>>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.

Please let us discuss this some more.  I am not swayed that we should 
include application behaviours in the specification and conformance 
clauses.  I think the specification should state the interpretation 
of the file format in terms of the file contents.

I'm still of the opinion phrases like "an application must signal an 
error to the user" are not appropriate for a file format specification.

Even the XML specification is a specification of the information 
delivered to an application from a stream of bytes: "Extensible 
Markup Language, abbreviated XML, describes a class of data objects 
called XML documents and partially describes the behavior of computer 
programs which process them." 
(http://www.w3.org/TR/2006/REC-xml-20060816 section 1.0 Introduction)

If genericode is to include application behaviours then these should 
be in the scope, in the specification proper and then can be cited 
from the conformance clauses.  But I'm not yet convinced.

Would others with an opinion on this please comment?  I will back 
down if others do not agree with my comments, but I think this needs 
more discussion.

Thanks!

. . . . . . . . . . . . Ken

--
Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal