OASIS Emergency Management TC

The EM-TC call will be not longer than 1 hour beginning at 12:00 
EDT.  Dial in number 605-725-3600 Pass code 236489.

Agenda
Attendance
Meeting notes from 8/21
HAVE - addition of conformance section
Profiles
Requirements for GIS SC wrt CAP and CWID input
Other Bus:
   Liaison w/IETF
   WS-Security -> ITU?
SC Reports:

Hi

Here are the links to a couple of specifications ("Profiles") published by
the Web Services Interoperability Consortium (WS-I), which I think are very
interesting in the context of our current discussion on conformance.

- "Basic Profile 1.1"

http://www.ws-i.org/Profiles/BasicProfile-1.1.html

- "Attachment Profile 1.0"

http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html

Note that I am not referring to the special characteristics that these
specifications have as "profiles" of other specifications (WSDL 1.1, SOAP
1.1, etc.).  I am only referring to their conformance-related aspects.

Also note that I am not implying that the approach followed in these
specifications should be followed literally in our specifications.  However,
I do believe that they contain several excellent ideas and that we could
think about borrowing some of them in our future work.  Indeed, I believe
that the OASIS draft guidelines on conformance are very close to the
approach followed in these specifications.

Here are a few passages that I consider relevant to the present discussion:


-----------------------------------------
Testability

When possible, the Profile makes statements that are testable. However, such
testability is not required. Preferably, testing is achieved in a
non-intrusive manner (e.g., examining artifacts "on the wire").


Strength of requirements

The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever
feasible; if there are legitimate cases where such a requirement cannot be
met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional
and conditional requirements introduce ambiguity and mismatches between
implementations.


Conformance targets

Where possible, the Profile places requirements on artifacts (e.g., WSDL
descriptions, SOAP messages) rather than the producing or consuming
software's behaviors or roles. Artifacts are concrete, making them easier to
verify and therefore making conformance easier to understand and less
error-prone.
-----------------------------------------



-----------------------------------------
Conformance to the Profile is defined by adherence to the set of
requirements defined for a specific target, within the scope of the Profile.

-----------------------------------------


-----------------------------------------
Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD)
indicate the nature of the requirement and its impact on conformance. Each
requirement is individually identified (e.g., R9999) for convenience.

For example

R9999 WIDGETs SHOULD be round in shape.

This requirement is identified by "R9999", applies to the target WIDGET (see
below), and places a conditional requirement upon widgets; i.e., although
this requirement must be met to maintain conformance in most cases, there
are some situations where there may be valid reasons for it not being met
(which are explained in the requirement itself, or in its accompanying
text).
-----------------------------------------


-----------------------------------------
Each requirement statement contains exactly one requirement level keyword
(e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The
conformance target keyword appears in bold text (e.g. "MESSAGE"). Other
conformance targets appearing in non-bold text are being used strictly for
their definition and NOT as a conformance target. Additional text may be
included to illuminate a requirement or group of requirements (e.g.,
rationale and examples); however, prose surrounding requirement statements
must not be considered in determining conformance.
-----------------------------------------


-----------------------------------------
Conformance targets identify what artifacts (e.g., SOAP message, WSDL
description, UDDI registry data) or parties (e.g., SOAP processor, end user)
requirements apply to.

This allows for the definition of conformance in different contexts, to
assure unambiguous interpretation of the applicability of requirements, and
to allow conformance testing of artifacts (e.g., SOAP messages and WSDL
descriptions) and the behavior of various parties to a Web service (e.g.,
clients and service instances).

Requirements' conformance targets are physical artifacts wherever possible,
to simplify testing and avoid ambiguity.
-----------------------------------------


-----------------------------------------
The following conformance targets are used in the Profile:

MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP
messages)

ENVELOPE - the serialization of the soap:Envelope element and its content

DESCRIPTION - descriptions of types, messages, interfaces and their concrete
protocol and data format bindings, and the network access points associated
with Web services (e.g., WSDL descriptions)

INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate

CONSUMER - software that invokes an INSTANCE

SENDER - software that generates a message according to the protocol(s)
associated with it

RECEIVER - software that consumes a message according to the protocol(s)
associated with it (e.g., SOAP processors)

REGDATA - registry elements that are involved in the registration and
discovery of Web services (e.g. UDDI tModels)
-----------------------------------------


Alessandro

Alenssandro,

Thanks for providing these explanations/definitions.  I encourage 
everyone looking into how we as a TC approach the conformance topic 
in our documents take a look and weigh in.  If you have specific 
knowledge of how our standards are being testing in particular 
applications and architectures, it would be helpful to know how 
conformance is defined there as well.

Sukumar has the task of being the editor of the first Document coming 
out of our TC that must have this new conformance section.  The 
approach we take will lay the foundation for how we'll do this going 
forward.  Please have a look at this and the other information on the 
TC and msg-SC lists and express your thoughts.

We will target our next TC call on 9/18 to vote on the draft and 
review of HAVE with this included.  That means, we need to come to 
some consensus in the next week.  Let's try to do that on the list.

Thanks,
Elysa

At 12:44 PM 9/4/2007, you wrote:
>Hi
>
>Here are the links to a couple of specifications ("Profiles") published by
>the Web Services Interoperability Consortium (WS-I), which I think are very
>interesting in the context of our current discussion on conformance.
>
>- "Basic Profile 1.1"
>
>http://www.ws-i.org/Profiles/BasicProfile-1.1.html
>
>- "Attachment Profile 1.0"
>
>http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html
>
>Note that I am not referring to the special characteristics that these
>specifications have as "profiles" of other specifications (WSDL 1.1, SOAP
>1.1, etc.).  I am only referring to their conformance-related aspects.
>
>Also note that I am not implying that the approach followed in these
>specifications should be followed literally in our specifications.  However,
>I do believe that they contain several excellent ideas and that we could
>think about borrowing some of them in our future work.  Indeed, I believe
>that the OASIS draft guidelines on conformance are very close to the
>approach followed in these specifications.
>
>Here are a few passages that I consider relevant to the present discussion:
>
>
>-----------------------------------------
>Testability
>
>When possible, the Profile makes statements that are testable. However, such
>testability is not required. Preferably, testing is achieved in a
>non-intrusive manner (e.g., examining artifacts "on the wire").
>
>
>Strength of requirements
>
>The Profile makes strong requirements (e.g., MUST, MUST NOT) wherever
>feasible; if there are legitimate cases where such a requirement cannot be
>met, conditional requirements (e.g., SHOULD, SHOULD NOT) are used. Optional
>and conditional requirements introduce ambiguity and mismatches between
>implementations.
>
>
>Conformance targets
>
>Where possible, the Profile places requirements on artifacts (e.g., WSDL
>descriptions, SOAP messages) rather than the producing or consuming
>software's behaviors or roles. Artifacts are concrete, making them easier to
>verify and therefore making conformance easier to understand and less
>error-prone.
>-----------------------------------------
>
>
>
>-----------------------------------------
>Conformance to the Profile is defined by adherence to the set of
>requirements defined for a specific target, within the scope of the Profile.
>
>-----------------------------------------
>
>
>-----------------------------------------
>Requirement levels, using RFC2119 language (e.g., MUST, MAY, SHOULD)
>indicate the nature of the requirement and its impact on conformance. Each
>requirement is individually identified (e.g., R9999) for convenience.
>
>For example
>
>R9999 WIDGETs SHOULD be round in shape.
>
>This requirement is identified by "R9999", applies to the target WIDGET (see
>below), and places a conditional requirement upon widgets; i.e., although
>this requirement must be met to maintain conformance in most cases, there
>are some situations where there may be valid reasons for it not being met
>(which are explained in the requirement itself, or in its accompanying
>text).
>-----------------------------------------
>
>
>-----------------------------------------
>Each requirement statement contains exactly one requirement level keyword
>(e.g., "MUST") and one conformance target keyword (e.g., "MESSAGE"). The
>conformance target keyword appears in bold text (e.g. "MESSAGE"). Other
>conformance targets appearing in non-bold text are being used strictly for
>their definition and NOT as a conformance target. Additional text may be
>included to illuminate a requirement or group of requirements (e.g.,
>rationale and examples); however, prose surrounding requirement statements
>must not be considered in determining conformance.
>-----------------------------------------
>
>
>-----------------------------------------
>Conformance targets identify what artifacts (e.g., SOAP message, WSDL
>description, UDDI registry data) or parties (e.g., SOAP processor, end user)
>requirements apply to.
>
>This allows for the definition of conformance in different contexts, to
>assure unambiguous interpretation of the applicability of requirements, and
>to allow conformance testing of artifacts (e.g., SOAP messages and WSDL
>descriptions) and the behavior of various parties to a Web service (e.g.,
>clients and service instances).
>
>Requirements' conformance targets are physical artifacts wherever possible,
>to simplify testing and avoid ambiguity.
>-----------------------------------------
>
>
>-----------------------------------------
>The following conformance targets are used in the Profile:
>
>MESSAGE - protocol elements that transport the ENVELOPE (e.g., SOAP/HTTP
>messages)
>
>ENVELOPE - the serialization of the soap:Envelope element and its content
>
>DESCRIPTION - descriptions of types, messages, interfaces and their concrete
>protocol and data format bindings, and the network access points associated
>with Web services (e.g., WSDL descriptions)
>
>INSTANCE - software that implements a wsdl:port or a uddi:bindingTemplate
>
>CONSUMER - software that invokes an INSTANCE
>
>SENDER - software that generates a message according to the protocol(s)
>associated with it
>
>RECEIVER - software that consumes a message according to the protocol(s)
>associated with it (e.g., SOAP processors)
>
>REGDATA - registry elements that are involved in the registration and
>discovery of Web services (e.g. UDDI tModels)
>-----------------------------------------
>
>
>Alessandro

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

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

 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Sunday, September 09, 2007 17:16
> 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 


I agree.  The current draft uses the term "(HAVE) message".  Perhaps "HAVE
document" or "HAVE report" or "report" would be better than "message".

Alessandro


> but all of these usages are 
> okay with me.
> 
> Cheers,
> Rex
> 

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

 

> 

                                                

					
                                                    

        
                                                
				
                                                

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