RE: [emergency] Use Case

[Rex Brooks <rexb@starbourne.com>]

I don't have a problem with this, but the fact is that we do need to 
make a definitive statement for EIC, and I'm not going to stand in 
the way of moving forward to OASIS approval. So what I would propose 
is adopting a position that stands behind the conformance section, 
but draws the distinction between conformance and how much of the 
specification needs to implemented.

Perhaps we could say:

"While the conformance section does not mandate that all specific 
message types must be implemented, we suggest implementors develop 
against the set of message types they consider necessary for their 
purposes. We would appreciate if implementors who are OASIS member 
companies test their implementations during development and issue a 
Statement of Use when they are satisfied that their implementations 
are functioning correctly for the minimum requirements of the 
conformance section."

We could fine tune such language to satisfy the needs of EIC for 
providing guidance on this topic.

Cheers,
Rex

At 12:02 AM -0400 4/18/08, Alessandro Triglia wrote:
>
>
>>  -----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


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670