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

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

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


Subject: Re: [codelist] Re: Updated genericode specification


We are simply chasing our tails here.  If we are going to get to some  
resolution of this thread in finite time, we need to stop arguing at  
cross-purposes.

In particular, we simply aren't agreeing from the outset as to what  
*conformance* is, and what the scope of it should be for the genericode  
specification.  Although this is only marginally less vague a topic than  
many of the great philosophical questions of history (like what "love"  
is), we still need to get to a sufficient agreement on what the question  
is or we will never agree what the answer is.

It's become clear to me that Ken and I have different views on how much of  
the "code list lifecycle" should be covered by the conformance.  Ken's  
view seems to be (and forgive me for paraphrasing) that the important part  
of the lifecycle is the authoring of genericode documents, and that if  
those are valid and self-consistent, then anything that happens after that  
is somebody else's problem.

By contrast, my view is that we need to be concerned not only with whether  
genericode documents are valid, but also whether applications process the  
genericode-specific parts of the information content in a consistent and  
repeatable way.  Users are free to put all kinds of information in  
genericode documents, and interpret their own information as they like.   
However, the same code list (which may span multiple genericode files due  
to references) should not, in my opinion, appear to contain different  
information depending on which application opens it (excepting differences  
due to applications having different local copies of the same genericode  
file).  For that reason, I believe that interpretation of the "structural  
semantics" (for want of a better expression) of genericode is an important  
and valid part of the scope of conformance, because it impacts directly on  
users perceptions and measurements of whether they get consistent  
behaviour from consuming applications or not.

I also disagree with Ken's brief explanation of what conformance is (i.e.  
a short check list of the major points from the spec), and I don't think  
that is how OASIS would define it.  I know the check list approach was  
mentioned as one possible interpretation, but I suspect that the inclusion  
of conformance as a separate issue for OASIS specs has been driven by Web  
services and the like, where it has not been uncommon see different  
implementations all adhering to the written specification, but via  
differing interpretations that are not interoperable.  This kind of  
problem is no less important for genericode users.

Anyway, how about we start with discussing how much of the "code list  
lifecycle" we can and should cover with conformance clauses?  Once we  
agree on that, I think some of the answers will come more easily.  By the  
way, part of the answer could be that we end up splitting the conformance  
clauses into "authoring" and "processing" sections, so that nobody feels  
duty bound to try and comply with conformance clauses that aren't relevant  
to the part of the lifecycle that they are responsible for.

Cheers, Tony.

On Tue, 04 Sep 2007 17:41:21 +0100, G. Ken Holman  
<gkholman@CraneSoftwrights.com> wrote:

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



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


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