RE: [emergency] Considerations on conformance for the HAVE standard

["Dwarkanath, Sukumar" <Sukumar_Dwarkanath@sra.com>]

All, 

This looks good to me and is a good start. Alessandro: Thanks for taking
a crack at it. Below are my initial thoughts:

Some "applications" may aggregate multiple HAVE messages. We can either
expand the concept of "producer" to include it, or specify another
compliance target. 

Do we need to identify a "consumer" - I know there isn't anything
specific about it in the spec - but I wanted to make sure that we
account for it. 

We need to understand how conformance fits with the use of other
standards in the spec - EDXL-DE and CIQ.

Thanks

Sukumar



-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com] 
Sent: Sunday, September 09, 2007 5:16 PM
To: Alessandro Triglia; 'Elysa Jones'; emergency@lists.oasis-open.org;
Dwarkanath, Sukumar; 'Michelle Raymond'
Subject: Re: [emergency] Considerations on conformance for the HAVE
standard

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