RE: [emergency] Use Case

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

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Thursday, April 17, 2008 23:01
> To: Dwarkanath, Sukumar; Elysa Jones; emergency@lists.oasis-open.org
> Subject: RE: [emergency] Use Case
> 
> We will probably end up just saying that the conformance section 
> requirements are sufficient without giving any other criteria.
> 
> For me, the issue is not conformance, it is "how much" of the RM spec 
> do we want to ask producers to implement in order to make a 
> "Statement of Use? However much of the spec is implemented, it needs 
> to satisfy the conformance requirements. The key concept in the RM 
> conformance section is in Level 2 where "it" refers to an EDXL-RM 
> producer:
> 
> b)   it produces a conforming Level-2 EDXL-RM Message when such a 
> message is expected.
> 
> What we haven't decided is what "expected" means. It can be one of 
> our specific Message Types, Level 1 conformance, Level 2 conformance 
> or all of them.
> 
> I'm not going to dig in my heels on this. Getting the spec approved 
> trumps my desire to ensure that the messages for a minimum resource 
> lifecycle is implemented. My concern is that a producer could confuse 
> the minimum requirement for a "Statement of Use" with a 
> TC-recommended practice.


I understand your concern, but I do believe that we should not try to
specify supplementary requirements for the statements of use that are not
rooted in the conformance section and expressed in the language of the
conformance section.  For example, the current text of the conformance
section does not define a concept of a minimum set of message types, and
therefore we should not impose a requirement for the statements of use that
says that an implementation must be able to handle a minimum set of message
types.  If we did that, it would be like admitting that the standard is weak
or incomplete, since such an important requirement is missing.  Essentially,
either this is an essential requirement or it is not.  If it is an essential
requirement then it should be in the standard.  If it is not, then I believe
it is not appropriate to impose it for the sake of the statements of use.

My impression is that some new requirements for the standard are coming up
now as people reflect on how the RM standard should be used.  Perhaps those
requirements had always been in people's minds as unspoken assumptions (I
don't know if that's the case), but the reality is that we didn't express
those requirements in the text.  For example, if the concept of a resource
lifecycle is essential for the RM standard (I don't know if it is), this
concept should be reflected in one or more specific provisions of the
standard, but today it isn't.  If those requirements are really important
for the successful use of RM, then perhaps we should take a step back and
specify them in the standard--but I am not suggesting that we do that.  I
would rather postpone this addition until the next version of the standard.
I believe we should put this standard out of the door as soon as possible
(which means in its present form).

The above does not imply that the TC should avoid giving (informal)
guidelines to implementers and users about such things as resource
lifecycles.  Obviously there is nothing wrong with this.  For example, I
think it would even be acceptable to say that we expect someone who provides
a statement of use to support a variety of message types.  The distinction I
am making is between us making a kind request and formulating a requirement.

Alessandro