Re: [emergency] Considerations on conformance for the HAVEstandard

[Rex Brooks <rexb@starbourne.com>]

Thanks Alessandro,

This satisfies my concerns because a "producer" can apply to a 
hospital, an implementation, e.g. a software tool built to produce 
conforming EDXL-HAVE documents or a service contracted to produce 
conforming EDXL-HAVE documents. I can live with the term "message," 
though it borders on being more vague and more prone to different 
interpretations than I would like, but I can see where the ambiguity 
might actually be useful. I usually prefer to reserve the term 
message for a documents specific to a messaging protocol like SOAP 
but all of these usages are okay with me.

Cheers,
Rex



At 4:10 PM -0400 9/9/07, Alessandro Triglia wrote:
>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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670