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. 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.
Howard Mason
Corporate IT Office
Tel: +44 1252 383129
Mob: +44 780 171 3340
Eml: howard.mason@baesystems.com
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
*** WARNING ***
This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.
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