OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


 

> -----Original Message-----
> From: Dwarkanath, Sukumar [mailto:Sukumar_Dwarkanath@sra.com] 
> Sent: Monday, September 10, 2007 18:30
> To: Rex Brooks; Alessandro Triglia; Elysa Jones; 
> emergency@lists.oasis-open.org; Michelle Raymond
> 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. 


It's certainly an important role in an exchange of HAVE reports, and we
could add some words about it at least in a descriptive way.  However, in
order for it to be a meaningful conformance target, there must be at least
one normative statement relative to it in the standard.  I am not yet sure
what we can require of a consumer, though.  In general the producer role and
the consumer role are not symmetric with respect to conformance.  In EDXL-RM
I believe both parties (requester and responder) should be conformance
targets, but in HAVE I am not sure.


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


Yes.  In my view that has to do more with conformance classes than with
conformance targets.  In other words, the target is the same, but there may
be several classes of the same target,  For example, one class of producer
might use only one restricted kind of CIQ address, and another class might
want to use CIQ in an less restrictive way (while still conforming to CIQ,
of course).

Alessandro


> 
> 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
> 

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]