OASIS Emergency Management TC

In the past these have been two completely separate activities.
 
Once the specification is approved - then compliance and conformance activities can be established.
 
However - OASIS has attempted to tighten the onus on members making statements of use and validation of the specification - so they are not superficial.
 
I would suggest that we still have to take these things in good faith - and trust that the level of due diligence is sufficient.
 
"Your actual mileage may vary" is the phrase that constantly resonates here.
 
For example - vendor X or agency Z may be going full bore on a major implementation of specification Y with a 20 man team working around the clock.  One expects that they will have thrown a ton of dirt out of the hole and found most of the rocks by now - and that feedback be passed to the TC.
 
Conversely - another TC maybe producing a specification that is 2 to 3 years ahead of where the market currently is.  This may be a small group - or a research department - close to the theory and practice in the domain - but nevertheless - producing a new paradigm.  One expects that implementation will be based on testbeds and experimental inclusion into production test systems - to verify a subset of function.
 
The key here is that people want to know when they vote on something that it has at least been tried in some capacity and been found to be successfully applicable.  Therefore the statements of use should give indication of the scope and extent.
 
As always - people expect a V1.0 specification to mature over time - while a Version 3.0 clearly represents substantial investment and feedback.
 
In between is a large amount of outreach and hand holding to take a specification from the drawing board to wide adoption and use.

Bottom line is we really need to leave it up to each member to make a statement they are comfortable with - and then to either accept that - or require additional members in order to cover the breadth we may sense is needed.
 
Thanks, DW






                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                
                                                
                                            
                                        

 

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: David RR Webber (XML) [mailto:david@drrw.info] 
> Sent: Thursday, April 17, 2008 13:04
> To: Alessandro Triglia
> Cc: 'Elysa Jones'; emergency@lists.oasis-open.org
> Subject: RE: [emergency] Use Case
> 
> In the past these have been two completely separate activities.


Are you referring to "development of a standard" and "development of a
conformance testing methodology for that standard" as being those two
separate activities?

If yes, I agree with you, but this is not what I was referring to.  I was
referring to the text, included as a "conformance section" (or "conformance
clause" in ISO) in the standard, which specifies the conformance criteria
for that standard. 

I would agree that a conformance testing methodology or a conformance
testing suite (with test cases, assertions, and so on) is a completely
separate activity, if that's what you were referring to.  However, the
drafting of a conformance clause in a standard, in my view, is a fundamental
part of developing a standard.

Some standards contain, in addition to the conformance clause, a proforma
conformance statement (e.g., a PICS) -- a form with check boxes, text
fields, and so on, which makes it very easy for implementers to express a
claim of conformance, that is, to say exactly what they conform to, and for
the buyers to understand in what sense a particular product is conforming to
the standard.  It makes it extremely clear what one means when he says that
his implementation is conforming to the standard.  This is especially useful
when a standard has multiple conformance classes/levels and optional
features.  I am not suggesting that our standards should literally include a
PICS, but having a very clear conformance section is important.  Too many
problems are caused by the lack of clarity on what it means for an
implementation to conform to a standard.


>  
> Once the specification is approved - then compliance and 
> conformance activities can be established.


Again, I agree with you if you are talking about a conformance testing
methodology and test suite.  Not if you are referring to the basic fact of
defining what it means for something to conform to the standard. 


>  
> However - OASIS has attempted to tighten the onus on members 
> making statements of use and validation of the specification 
> - so they are not superficial.
>  
> I would suggest that we still have to take these things in 
> good faith - and trust that the level of due diligence is sufficient.
>  
> "Your actual mileage may vary" is the phrase that constantly 
> resonates here.
>  
> For example - vendor X or agency Z may be going full bore on 
> a major implementation of specification Y with a 20 man team 
> working around the clock.  One expects that they will have 
> thrown a ton of dirt out of the hole and found most of the 
> rocks by now - and that feedback be passed to the TC.
>  
> Conversely - another TC maybe producing a specification that 
> is 2 to 3 years ahead of where the market currently is.  This 
> may be a small group - or a research department - close to 
> the theory and practice in the domain - but nevertheless - 
> producing a new paradigm.  One expects that implementation 
> will be based on testbeds and experimental inclusion into 
> production test systems - to verify a subset of function.
>  
> The key here is that people want to know when they vote on 
> something that it has at least been tried in some capacity 
> and been found to be successfully applicable.  Therefore the 
> statements of use should give indication of the scope and extent.


Precisely.  I believe the statement of use should say what their
implementation does, in terms of the actual conformance section present in
the standard.

I agree that we can leave it up to each member to decide what conformance
class/level and which options they want to implement in order to produce an
acceptable statement of use.

Alessandro


>  
> As always - people expect a V1.0 specification to mature over 
> time - while a Version 3.0 clearly represents substantial 
> investment and feedback.
>  
> In between is a large amount of outreach and hand holding to 
> take a specification from the drawing board to wide adoption and use.
> 
> Bottom line is we really need to leave it up to each member 
> to make a statement they are comfortable with - and then to 
> either accept that - or require additional members in order 
> to cover the breadth we may sense is needed.
>  
> Thanks, DW
> 
> 

Hi folks,



  Sorry for interjecting again. When I read the previous
messages, I thought that some companies (non-OASIS members) wanted to be able
to say that their product/service/etc conformed to a particular specification
and therefore needed an actual conformance statement in the specification so
that they would know what the requirements are. (i.e.
certification/compliance). As David says, you can’t build
conformance/compliance tests without knowing exactly what is required and what
is optional in various scenarios. Now I’m getting the impression that
this is tied to the OASIS TC Process requirement for 3 Statements of Use that
must be submitted in order to move forward with an OS Submission ballot. Those
Statements of Use:

a)     
Should say exactly what is required by the TC Process, no less
(and most often, no more)

b)     
Must be from OASIS Organizational Members



My apologies for not being thoroughly engaged in the overall
conversation; I’ve spent the last few days worrying about a close family
member and many hours at the hospital, but I don’t want to see the TC
spending cycles that may result in over-engineering ;-)



Regards,



Mary 







From: David RR Webber
(XML) [mailto:david@drrw.info]

Sent: Thursday, April 17, 2008 1:04 PM

To: Alessandro Triglia

Cc: 'Elysa Jones'; emergency@lists.oasis-open.org

Subject: RE: [emergency] Use Case









In the past these have been two completely separate
activities.





 





Once the specification is approved - then compliance and
conformance activities can be established.





 





However - OASIS has attempted to tighten the onus on members
making statements of use and validation of the specification - so they are not
superficial.





 





I would suggest that we still have to take these things in
good faith - and trust that the level of due diligence is sufficient.





 





"Your actual mileage may vary" is the phrase
that constantly resonates here.





 





For example - vendor X or agency Z may be going full
bore on a major implementation of specification Y with a 20 man team working
around the clock.  One expects that they will have thrown a ton of dirt
out of the hole and found most of the rocks by now - and that feedback be
passed to the TC.





 





Conversely - another TC maybe producing a specification that
is 2 to 3 years ahead of where the market currently is.  This may be a
small group - or a research department - close to the theory and practice
in the domain - but nevertheless - producing a new paradigm.  One expects
that implementation will be based on testbeds and experimental inclusion into
production test systems - to verify a subset of function.





 





The key here is that people want to know when they vote on
something that it has at least been tried in some capacity and been found to be
successfully applicable.  Therefore the statements of use should give
indication of the scope and extent.





 





As always - people expect a V1.0 specification to mature
over time - while a Version 3.0 clearly represents substantial investment and
feedback.





 





In between is a large amount of outreach and hand holding to
take a specification from the drawing board to wide adoption and use.





Bottom line is we really need to leave it up to each member
to make a statement they are comfortable with - and then to either accept that
- or require additional members in order to cover the breadth we may sense is
needed.





 





Thanks, DW













                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                 Original Message
--------

Subject: RE: [emergency] Use Case

From: "Alessandro Triglia" <sandro@oss.com>

Date: Thu, April 17, 2008 11:07 am

To: "'Elysa Jones'" <ejones@warningsystems.com>,

<emergency@lists.oasis-open.org>



In my view this is straightforward. The statement of use should be strictly

based upon the conformance clause. We can't set requirements for a

statement of use that are more stringent than the conformance requirements

specified in the standard itself.


If the conformance section of a standard says that an implementation
"X" is

conformant if and only if it does "Y", then all that the statement of
use

really needs to say is something like, "Here is an implementation X of
this

standard, which I certify to be conformant to the standard".


If the standard specifies multiple conformance targets, the statement of use

needs to say which target is being referred to.


If the standard specifies multiple conformance classes or levels, the

statement of use needs to say which conformance class or conformance level

is being referred to.


In other words, in my view, a statement of use should simply state that the

OASIS member organization has created an implementation of a standard and

should contain a conformance claim about that implementation. Like any

other conformance claim, that conformance claim should simply and very

clearly reference the particular conformance target, conformance class,

conformance level, and any conformance options that are specified in the

standard (if any).


The conformance section of RM (as of today) doesn't say that implementations

must support a complete lifecycle of a successful resource deployment.

Therefore we cannot impose that kind of requirement on the statement of use.

If the TC believes that all implementations of RM should really support a

complete lifecycle of a successful resource deployment, then we should

change the standard to specify that requirement either in the conformance

section or elsewhere.


Alessandro




> 
                                            
                                        

                                        
                                        

                                    
			

Hi Mary,

In various exchanges, we have arrived at what I think will be the 
consensus, and it matches a) and b).

We are concerned with obtaining the Statements of Use mostly, but 
also with encouraging adoption and implementation. The EIC wanted us 
to provide guidance, (hoping to encourage some members of that org, 
or associates of that org to join OASIS, too) and that's what we are 
doing.

Cheers,
Rex

At 9:47 AM -0400 4/18/08, Mary McRae wrote:
>Hi folks,
>
>   Sorry for interjecting again. When I read the previous messages, I 
>thought that some companies (non-OASIS members) wanted to be able to 
>say that their product/service/etc conformed to a particular 
>specification and therefore needed an actual conformance statement 
>in the specification so that they would know what the requirements 
>are. (i.e. certification/compliance). As David says, you can't build 
>conformance/compliance tests without knowing exactly what is 
>required and what is optional in various scenarios. Now I'm getting 
>the impression that this is tied to the OASIS TC Process requirement 
>for 3 Statements of Use that must be submitted in order to move 
>forward with an OS Submission ballot. Those Statements of Use:
>a)      Should say exactly what is required by the TC Process, no 
>less (and most often, no more)
>b)      Must be from OASIS Organizational Members
>
>My apologies for not being thoroughly engaged in the overall 
>conversation; I've spent the last few days worrying about a close 
>family member and many hours at the hospital, but I don't want to 
>see the TC spending cycles that may result in over-engineering ;-)
>
>Regards,
>
>Mary
>
>From: David RR Webber (XML) [mailto:david@drrw.info]
>Sent: Thursday, April 17, 2008 1:04 PM
>To: Alessandro Triglia
>Cc: 'Elysa Jones'; emergency@lists.oasis-open.org
>Subject: RE: [emergency] Use Case
>
>In the past these have been two completely separate activities.
>
>Once the specification is approved - then compliance and conformance 
>activities can be established.
>
>However - OASIS has attempted to tighten the onus on members making 
>statements of use and validation of the specification - so they are 
>not superficial.
>
>I would suggest that we still have to take these things in good 
>faith - and trust that the level of due diligence is sufficient.
>
>"Your actual mileage may vary" is the phrase that constantly resonates here.
>
>For example - vendor X or agency Z may be going full bore on a major 
>implementation of specification Y with a 20 man team working around 
>the clock.  One expects that they will have thrown a ton of dirt out 
>of the hole and found most of the rocks by now - and that feedback 
>be passed to the TC.
>
>Conversely - another TC maybe producing a specification that is 2 to 
>3 years ahead of where the market currently is.  This may be a small 
>group - or a research department - close to the theory and practice 
>in the domain - but nevertheless - producing a new paradigm.  One 
>expects that implementation will be based on testbeds and 
>experimental inclusion into production test systems - to verify a 
>subset of function.
>
>The key here is that people want to know when they vote on something 
>that it has at least been tried in some capacity and been found to 
>be successfully applicable.  Therefore the statements of use should 
>give indication of the scope and extent.
>
>As always - people expect a V1.0 specification to mature over time - 
>while a Version 3.0 clearly represents substantial investment and 
>feedback.
>
>In between is a large amount of outreach and hand holding to take a 
>specification from the drawing board to wide adoption and use.
>Bottom line is we really need to leave it up to each member to make 
>a statement they are comfortable with - and then to either accept 
>that - or require additional members in order to cover the breadth 
>we may sense is needed.
>
>Thanks, DW
>
>
>
>

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                 Original Message --------
>Subject: RE: [emergency] Use Case
>From: "Alessandro Triglia" 

Thanks Rex!

Let me know if there's anything I can do to help. It sounds like it might also
be something for the adoption subcommittee to handle in terms of "implementation
guidelines" or "best practices" maybe?

And thanks for the thoughts and prayers - my nephew is actually on his way home
from the hospital after having a golf-ball-sized brain tumor removed on
Wednesday. All indications are that it was benign although it will be a week
before the final pathology reports are in.

Mary

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Friday, April 18, 2008 10:12 AM
> To: mary.mcrae@oasis-open.org; 'David RR Webber (XML)'; 'Alessandro
> Triglia'
> Cc: 'Elysa Jones'; emergency@lists.oasis-open.org
> Subject: RE: [emergency] Use Case
> 
> Hi Mary,
> 
> In various exchanges, we have arrived at what I think will be the
> consensus, and it matches a) and b).
> 
> We are concerned with obtaining the Statements of Use mostly, but
> also with encouraging adoption and implementation. The EIC wanted us
> to provide guidance, (hoping to encourage some members of that org,
> or associates of that org to join OASIS, too) and that's what we are
> doing.
> 
> Cheers,
> Rex
> 
> At 9:47 AM -0400 4/18/08, Mary McRae wrote:
> >Hi folks,
> >
> >   Sorry for interjecting again. When I read the previous messages, I
> >thought that some companies (non-OASIS members) wanted to be able to
> >say that their product/service/etc conformed to a particular
> >specification and therefore needed an actual conformance statement
> >in the specification so that they would know what the requirements
> >are. (i.e. certification/compliance). As David says, you can't build
> >conformance/compliance tests without knowing exactly what is
> >required and what is optional in various scenarios. Now I'm getting
> >the impression that this is tied to the OASIS TC Process requirement
> >for 3 Statements of Use that must be submitted in order to move
> >forward with an OS Submission ballot. Those Statements of Use:
> >a)      Should say exactly what is required by the TC Process, no
> >less (and most often, no more)
> >b)      Must be from OASIS Organizational Members
> >
> >My apologies for not being thoroughly engaged in the overall
> >conversation; I've spent the last few days worrying about a close
> >family member and many hours at the hospital, but I don't want to
> >see the TC spending cycles that may result in over-engineering ;-)
> >
> >Regards,
> >
> >Mary
> >
> >From: David RR Webber (XML) [mailto:david@drrw.info]
> >Sent: Thursday, April 17, 2008 1:04 PM
> >To: Alessandro Triglia
> >Cc: 'Elysa Jones'; emergency@lists.oasis-open.org
> >Subject: RE: [emergency] Use Case
> >
> >In the past these have been two completely separate activities.
> >
> >Once the specification is approved - then compliance and conformance
> >activities can be established.
> >
> >However - OASIS has attempted to tighten the onus on members making
> >statements of use and validation of the specification - so they are
> >not superficial.
> >
> >I would suggest that we still have to take these things in good
> >faith - and trust that the level of due diligence is sufficient.
> >
> >"Your actual mileage may vary" is the phrase that constantly resonates
> here.
> >
> >For example - vendor X or agency Z may be going full bore on a major
> >implementation of specification Y with a 20 man team working around
> >the clock.  One expects that they will have thrown a ton of dirt out
> >of the hole and found most of the rocks by now - and that feedback
> >be passed to the TC.
> >
> >Conversely - another TC maybe producing a specification that is 2 to
> >3 years ahead of where the market currently is.  This may be a small
> >group - or a research department - close to the theory and practice
> >in the domain - but nevertheless - producing a new paradigm.  One
> >expects that implementation will be based on testbeds and
> >experimental inclusion into production test systems - to verify a
> >subset of function.
> >
> >The key here is that people want to know when they vote on something
> >that it has at least been tried in some capacity and been found to
> >be successfully applicable.  Therefore the statements of use should
> >give indication of the scope and extent.
> >
> >As always - people expect a V1.0 specification to mature over time -
> >while a Version 3.0 clearly represents substantial investment and
> >feedback.
> >
> >In between is a large amount of outreach and hand holding to take a
> >specification from the drawing board to wide adoption and use.
> >Bottom line is we really need to leave it up to each member to make
> >a statement they are comfortable with - and then to either accept
> >that - or require additional members in order to cover the breadth
> >we may sense is needed.
> >
> >Thanks, DW
> >
> >
> >
> >
 Original Message --------
> >Subject: RE: [emergency] Use Case
> >From: "Alessandro Triglia" 

Thanks Mary.

Best wishes for your nephew.

Cheers,
Rex

At 10:54 AM -0400 4/18/08, Mary McRae wrote:
>Thanks Rex!
>
>Let me know if there's anything I can do to help. It sounds like it might also
>be something for the adoption subcommittee to handle in terms of 
>"implementation
>guidelines" or "best practices" maybe?
>
>And thanks for the thoughts and prayers - my nephew is actually on 
>his way home
>from the hospital after having a golf-ball-sized brain tumor removed on
>Wednesday. All indications are that it was benign although it will be a week
>before the final pathology reports are in.
>
>Mary
>
>>  

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
>>  From: Rex Brooks [mailto:rexb@starbourne.com]
>>  Sent: Friday, April 18, 2008 10:12 AM
>>  To: mary.mcrae@oasis-open.org; 'David RR Webber (XML)'; 'Alessandro
>>  Triglia'
>>  Cc: 'Elysa Jones'; emergency@lists.oasis-open.org
>>  Subject: RE: [emergency] Use Case
>>
>>  Hi Mary,
>>
>>  In various exchanges, we have arrived at what I think will be the
>>  consensus, and it matches a) and b).
>>
>>  We are concerned with obtaining the Statements of Use mostly, but
>>  also with encouraging adoption and implementation. The EIC wanted us
>>  to provide guidance, (hoping to encourage some members of that org,
>>  or associates of that org to join OASIS, too) and that's what we are
>>  doing.
>>
>>  Cheers,
>>  Rex
>>
>>  At 9:47 AM -0400 4/18/08, Mary McRae wrote:
>>  >Hi folks,
>>  >
>>  >   Sorry for interjecting again. When I read the previous messages, I
>>  >thought that some companies (non-OASIS members) wanted to be able to
>>  >say that their product/service/etc conformed to a particular
>>  >specification and therefore needed an actual conformance statement
>>  >in the specification so that they would know what the requirements
>>  >are. (i.e. certification/compliance). As David says, you can't build
>>  >conformance/compliance tests without knowing exactly what is
>>  >required and what is optional in various scenarios. Now I'm getting
>>  >the impression that this is tied to the OASIS TC Process requirement
>>  >for 3 Statements of Use that must be submitted in order to move
>>  >forward with an OS Submission ballot. Those Statements of Use:
>>  >a)      Should say exactly what is required by the TC Process, no
>>  >less (and most often, no more)
>>  >b)      Must be from OASIS Organizational Members
>>  >
>>  >My apologies for not being thoroughly engaged in the overall
>>  >conversation; I've spent the last few days worrying about a close
>>  >family member and many hours at the hospital, but I don't want to
>>  >see the TC spending cycles that may result in over-engineering ;-)
>>  >
>>  >Regards,
>>  >
>>  >Mary
>>  >
>>  >From: David RR Webber (XML) [mailto:david@drrw.info]
>>  >Sent: Thursday, April 17, 2008 1:04 PM
>>  >To: Alessandro Triglia
>>  >Cc: 'Elysa Jones'; emergency@lists.oasis-open.org
>  > >Subject: RE: [emergency] Use Case
>>  >
>>  >In the past these have been two completely separate activities.
>>  >
>>  >Once the specification is approved - then compliance and conformance
>>  >activities can be established.
>>  >
>>  >However - OASIS has attempted to tighten the onus on members making
>>  >statements of use and validation of the specification - so they are
>>  >not superficial.
>>  >
>>  >I would suggest that we still have to take these things in good
>>  >faith - and trust that the level of due diligence is sufficient.
>>  >
>>  >"Your actual mileage may vary" is the phrase that constantly resonates
>>  here.
>>  >
>>  >For example - vendor X or agency Z may be going full bore on a major
>>  >implementation of specification Y with a 20 man team working around
>>  >the clock.  One expects that they will have thrown a ton of dirt out
>>  >of the hole and found most of the rocks by now - and that feedback
>>  >be passed to the TC.
>>  >
>>  >Conversely - another TC maybe producing a specification that is 2 to
>  > >3 years ahead of where the market currently is.  This may be a small
>>  >group - or a research department - close to the theory and practice
>>  >in the domain - but nevertheless - producing a new paradigm.  One
>>  >expects that implementation will be based on testbeds and
>>  >experimental inclusion into production test systems - to verify a
>>  >subset of function.
>>  >
>>  >The key here is that people want to know when they vote on something
>>  >that it has at least been tried in some capacity and been found to
>>  >be successfully applicable.  Therefore the statements of use should
>>  >give indication of the scope and extent.
>>  >
>>  >As always - people expect a V1.0 specification to mature over time -
>>  >while a Version 3.0 clearly represents substantial investment and
>>  >feedback.
>>  >
>>  >In between is a large amount of outreach and hand holding to take a
>>  >specification from the drawing board to wide adoption and use.
>>  >Bottom line is we really need to leave it up to each member to make
>>  >a statement they are comfortable with - and then to either accept
>>  >that - or require additional members in order to cover the breadth
>>  >we may sense is needed.
>>  >
>>  >Thanks, DW
>>  >
>>  >
>>  >
>>  >
 Original Message --------
>>  >Subject: RE: [emergency] Use Case
>>  >From: "Alessandro Triglia"