RE: [emergency] Use Case

["Mary McRae" <mary.mcrae@oasis-open.org>]

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-----
> 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" <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
> >
> >
> >
> >>  -----Original Message-----
> >>  From: Elysa Jones [mailto:<#Compose>ejones@warningsystems.com]
> >>  Sent: Thursday, April 17, 2008 10:30
> >>  To: <>emergency@lists.oasis-open.org
> >>  Subject: [emergency] Use Case
> >>
> >>  TC Members,
> >>
> >>  We would like to nail down the TC's consensus on what
> >>  constitutes a "Use case" in our Standards. Most of you have
> >>  been aware of this topic but we have not nailed down a
> >>  position. We must do this before we can make the big push to
> >>  get use cases for HAVE and RM.
> >>
> >>  This topic came up during the EIC meeting yesterday. There
> >>  are several EIC members that know of companies that may want
> >>  to be the first or one of the first to advertise such a use
> >>  case. We need to give them specific wording on what
> >>  constitutes this "use". OASIS requires the statement to be
> >>  in agreement with the conformance clause of the
> >>  specification. We as a TC can cause this to be more or less
> >>  stringent and there are schools of thought on both.
> >>
> >>  Please review the two positions on the matter identified
> >>  below and respond to the list on your preference. Although
> >>  this does not require a formal vote of the TC, I want to make
> >>  sure we have a good understanding and consensus on how we proceed.
> >>
> >>  Position 1:
> >>
> >>  * Comply with the full element reference model - required
> >>  elements at a minimum. If a message is sent that complies
> >>  with the ERM, then you can be compliant with any of the
> >>  specific messages.
> >>  * Deliver a RequestResource message and a
> >>  ResponsetoRequestResource message (just 2 messages).
> >>
> >>  If a vendor does either or, for purposes of statement of use
> >>  and getting the standard out the door, this should be the
> >>  minimum requirement.
> >>
> >>  Position 2:
> >>
> >>  * Agreed with position 1
> >>  * A complete lifecycle of a "successful" Resource
> >>  Deployment should be the minimum:
> >>
> >>  RequestResource >
> >>  ResponseToRequestResource >
> >>  RequisitionResource >
> >>  CommitResource >
> >>  ReleaseResource.
> >>
> >>  The messages about the deployment, requesting information,
> >>  release, etc are not necessary, just the 5 listed.
> >>
> >>  NOW - please make your comments to the list. The Mst/Not SC
> >  > will schedule a meeting either Fri (4/18) or Mon (4/21) to
> >>  discuss. From this a recommendation will be made. Respond
> >>  to this message too with which date and what times you would
> >>  be available.
> >>
> >>  Regards,
> >>  Elysa Jones
> >>  Chair, OASIS EM-TC
> >>  CTO/COO
> >>  Warning Systems, Inc.
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe from this mail list, you must leave the OASIS TC that
> >generates this mail. You may a link to this group and all your TCs in
> OASIS
> >at:
> ><https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php>https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >---------------------------------------------------------------------
> >To unsubscribe from this mail list, you must leave the OASIS TC that
> >generates this mail. You may a link to this group and all your TCs
> >in OASIS at:
> >https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php