RE: [emergency] Use Case

["Alessandro Triglia" <sandro@oss.com>]

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