RE: [codelist] Re: Updated genericode specification

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

At 2007-09-05 13:15 +0100, Mason, Howard \(UK\) wrote:
> From the perspective of our work on information exchange,
>interoperability will require conformance testing that a document which
>purports to comply with the specification is valid, and that an
>application which purports to accept a genericode document as input
>successfully interprets that document as intended - both reading the
>syntax and interpreting the semantics.

I agree these two are distinct ... especially given my desire to 
claim the files I publish are conformant (regardless of who uses 
them) and Tony's desire to claim applications using a genericode file 
are conformant.

>You may also have a third case,
>where you need to check that an application which purports to generate
>genericode documents does in fact produce compliant syntax and
>semantics.

I think that is covered by the first of the two just by looking at 
the end result as being a conformant file.

>-----Original Message-----
>From: Anthony B. Coates (Miley Watts) [mailto:abcoates@mileywatts.com]
>Sent: 05 September 2007 15:47
>To: Code List Representation TC
>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.

I didn't think we were.

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

I acknowledge this and as you state below, I don't see why we cannot 
have two sections in the conformance part of the spec:  one for a 
properly formed file, and one for a properly acting program.

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

Right there is an issue that doesn't sit well with me and 
"application conformance", but I'll accept it if there is a separate 
section on file conformance.  I've committed to the UBL TC to supply 
conformant genericode files and I don't think we need a running 
application to measure that.

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

But as you point out, they won't get consistent behaviour based on local files.

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

I totally agree.  I don't think we are working at cross purposes at all.

Mary, when an OASIS specification has a conformance clause, is it 
allowed to have sections whereby different subclauses are covered 
based on different perspectives of the same specification?

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