Considerations on conformance for the HAVE standard

["Alessandro Triglia" <sandro@oss.com>]

I am reading through the HAVE document.  As far as I can see, this standard
fundamentally specifies a **message** (or a document or a report if you
will).  It does not say much about the expected behavior of the producer of
the message or about the expected behavior of the consumer of the message,
or about anything else.  Indeed, the main normative section of this standard
consists entirely of a data dictionary for the HAVE message.

Today I woke up with the following thoughts.

I am thinking that HAVE needs **two** conformance targets:  "message" and
"message producer".

Most of the normative statements in this standard (most of them explicitly
or implicitly embedded in the data dictionary) can be read as referring to a
message (or could easily be reworded so as to refer to a message).  

There are a few statements here and there that seem to refer to the producer
of a message.  Perhaps some of those statements could be reworded so as to
refer to the message, but there may be others that genuinely refer to the
producer of the message.  This is one reason why I wouldn't rule out the
possibility of having the producer defined as a conformance target (in
addition to the message).

The other reason (perhaps more important) for having the producer as a
conformance target (in addition to the message) is this:  Defining the
"message" as the primary conformance target is very good for various reasons
(as I suggested in a previous email), but does not address a very important
aspect of conformance--the ability for vendors to make conformance claims
about their software products.  If the **only** thing that can meaningfully
be said to claim conformance to a standard "A" is a **message**, then it
becomes unclear what an "implementation" of that standard is.  People want
to be able to state that their application conforms to a standard "A", and
not just that one particular message conforms to that standard (although the
latter is also important).

I think the conformance section of HAVE could contain some text like this:

---------------------------------
A software entity is a conforming "producer of HAVE messages" according to
this standard if and only if it satisfies the following conditions:

a) it is constructed in such a way that any XML document produced by it and
present in a place in which a conforming HAVE message is expected (based on
contextual information) is indeed a conforming "HAVE message" according to
this standard; and

b) it satisfies the requirements in sections X, Y, Z, ...

The condition in (a) may be satisfied in many different ways, depending on
the particular scenario.  Here are some examples:

a) a standard protocol (say, EDXL-DE) transfers requests for HAVE messages
and responses carrying HAVE messages;  a client has sent a request to a
server which claims to be a conforming "producer of HAVE messages", and has
received a response which is therefore expected to carry a conforming HAVE
message;

b) a local test environment has been set up, and the application under test
(which claims to be a conforming "producer of HAVE messages") has the
ability to produce a HAVE message and write it to a file in a folder on a
hard disk in response to a request coming from the testing tool;  the
testing tool has sent many requests to the application and is now verifying
all the files present in the folder, which is expected to contain only
conforming HAVE messages;

c) a HAVE message is attached to an email message which, according to a
prior agreement between sender and recipient, is expected to carry a
conforming HAVE message;

d) a HAVE message has been published at a location on the World Wide Web,
identified by a known HTTP URL, from where it can be retrieved by using the
HTTP protocol, and the publisher has created the expectation among its
potential audience that that location will indeed contain a conforming HAVE
message.
---------------------------------


I am sure the above can be improved!  (Probably we don't need to list all
these examples.)

One comment about condition (a).  I struggled a little with the wording, but
I think "is costructed in such a way that..." is better than, say, "will
always produce conforming HAVE messages" or "was designed to produce
conforming HAVE messages".  I think "is costructed in such a way that..."
also avoids the issue of the significance of potential bugs in a conforming
implementation.  When discussing conformance, a recurring question is
whether a bug makes an implementation non-conforming.  If the existence of a
bug prevented conformance, then there would never be any conforming
implementations of anything (you can never exclude the existence of bugs in
any software product).  On the other hand, a manifestly buggy implementation
should never be declared conforming.  I think the solution needs to be
pragmatic (conformance testing).  The best way of dealing with testing of
conformance claims is to specify a conformance testing methodology and
publish it as a standard alongside the standard that is the object of
conformance.  The standard itself doesn't need to fully address the problem,
but it does need to enable a conformance testing methodology.  Specifying a
suitable set of conformance targets is part of that.

Any comments?

Alessandro