[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Considerations on conformance for the HAVE standard
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]