RE: EDXL-RM Statement Of Use

[Rex Brooks <rexb@starbourne.com>]

Hi All,

I'm for Friday, any time, but I can do Monday if needs be.

Cheers,
Rex

At 2:04 PM -0400 4/17/08, Timothy Grapes wrote:
>I think fantastic points are being made and we 
>have the foundation to move forward, but that we 
>should convene a conference call to finalize 
>discussion and determine appropriate steps and 
>communication.  Part of the catalyst here was to 
>publish a "plea" to the membership for companies 
>to provide RM Statements of Use, in order to 
>track progress as the standard nears the finish 
>line.  We need to agree on how that request 
>should be written.
>
>Could everyone interested in participating in 
>defining this approach and next step please 
>reply with your preference for FRIDAY or MONDAY, 
>please?
>
>For convenience I have pasted the EDXL-RM 
>conformance section below.  I am actually 
>advocating that any implementation of the 
>standard that adheres to this section would 
>equal a valid Statement of Use.  Recall that the 
>Level 1 and 2 Conformance options do address the 
>overall Element Reference Model, and then the 
>individual messages, but does not specify 
>specific ones or some minimum set.  Though I 
>agree with Rex's desire regarding a "complete 
>lifecycle of a successful resource deployment", 
>this is not applicable for Statement of Use 
>purposes, and that "complete lifecycle" may not 
>fully apply to the business processes of some 
>companies and their applications.  That's an 
>important objective ASAP, but I feel that 
>getting the draft standard through the process 
>and published is paramount in the immediate term.
>
>My 2-cents.  Let me know a day/time as we'll set it up.
>
>Thanks,
>Tim
>
>1        Conformance
>
>1.1 Conformance Targets
>
>The two following conformance targets are 
>defined in order to support the specification of 
>conformance to this standard:
>
>EDXL-RM Message; and
>
>
>EDXL-RM Message Producer.
>
>An EDXL-RM Message is an XML 1.0 element 
>whose syntax and semantics are specified in this 
>standard. An EDXL-RM Message Producer is a 
>software entity that produces EDXL-RM Messages.
>NOTE   There is no conformance target 
>corresponding to the consumers of EDXL-RM 
>messages. All the existing requirements for the 
>consumption of an incoming EDXL-RM message are, 
>in fact, requirements on the type and content of 
>the EDXL-RM message that is produced by the 
>consumer in reply to that message (if any). 
>Therefore, a conforming EDXL-RM Message Producer 
>(as defined in Section 5.4) will necessarily 
>meet all the existing requirements for the 
>production as well as for the consumption of 
>EDXL-RM messages.
>
>1.2 Conformance Levels
>
>The two following conformance levels are defined for EDXL-RM Messages:
>
>Level-1 EDXL-RM Message; and
>Level-2 EDXL-RM Message.
>NOTE   The conformance requirements for Level-1 
>and Level-2 EDXL-RM Messages are given in 
>Section 5.3, and summarized here. A Level-1 
>EDXL-RM Message is either one of the 16 resource 
>message elements specified in sections 3.4 to 
>3.19, or a different element (with a different 
>namespace name and an arbitrary local name) 
>whose type is the complex type 
>"EDXLResourceMessageReferenceType" specified in 
>Section 4.1.1. A Level-2 EDXL-RM Message is 
>restricted to be one of the 16 resource message 
>elements specified in sections 3.4 to 3.19. 
>Every Level-2 EDXL-RM Message is also a 
>conforming Level-1 EDXL-RM Message.
>The two following conformance levels are defined 
>for EDXL-RM Message Producers:
>
>Level-1 EDXL-RM Message Producer; and
>Level-2 EDXL-RM Message Producer.
>NOTE   The conformance requirements for Level-1 
>and Level-2 EDXL-RM Message Producers are given 
>in Section 5.4, and summarized here. A Level-1 
>EDXL-RM Message Producer is a software entity 
>that produces conforming (Level-1) EDXL-RM 
>Messages whenever a (Level-1) EDXL-RM Message is 
>expected. A Level-2 EDXL-RM Message Producer is 
>a software entity that only produces Level-2 
>EDXL-RM Messages whenever a Level-2 EDXL-RM 
>Message is expected. Every Level-2 EDXL-RM 
>Message Producer is also a conforming Level-1 
>EDXL-RM Message Producer.
>
>1.3 Conformance as an EDXL-RM Message
>
>1.3.1 Level-1 EDXL-RM Message
>
>An XML 1.0 element is a conforming Level-1 EDXL-RM Message if and only if:
>a)      it meets the general requirements specified in Section 3.3;
>
>b)      if its namespace name is 
>"urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg", 
>then its local name is one of the 16 resource 
>message type names specified in sections 3.4 to 
>3.19 (also listed in Table 1), and the element 
>is valid according to the schema located at
><http://docs.oasis-open.org/emergency/EDXL-RM/EDXL-RM.xsd>http://docs.oasis-open.org/emergency/EDXL-RM/EDXL-RM.xsd, 
>where validation is performed against the global 
>element declaration with the same local name;
>
>c)      if its namespace name is not 
>"urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg", 
>then the element is valid according to the 
>schema located at
><http://docs.oasis-open.org/emergency/EDXL-RM/EDXL-RM.xsd>http://docs.oasis-open.org/emergency/EDXL-RM/EDXL-RM.xsd, 
>where validation is performed against the 
>complex type definition 
>"EDXLResourceMessageReferenceType";
>
>d)     if its namespace name is 
>"urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg", 
>then its content (which includes the content of 
>each of its descendants) meets all the 
>additional mandatory requirements provided in 
>the specific subsection of Section 3 (sections 
>3.4 to 3.19) corresponding to the element's 
>name, with the exception of the Message Flow; 
>such requirements include:
>
>·         the content of the Element Reference Model;
>·         each of the Message Rules; and
>·         the normative parts (element name, 
>usage, and constraints) of any dictionary data 
>entries (in Section 4) corresponding to the 
>elements that actually occur in the content of 
>the element;
>
>e)      if its namespace name is not 
>"urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg", 
>then its content (which includes the content of 
>each of its descendants) meets all the 
>additional mandatory requirements provided in 
>the normative parts (element name, usage, and 
>constraints) of all the dictionary data entries 
>(in Section 4) corresponding to the elements 
>that actually occur in the content of the 
>element.
>NOTE The Information Exchange Package 
>Documentation (IEPD) process, specified within 
>the United States National Information Exchange 
>Model (available on www.niem.gov), can be used 
>by a Community of Interest when specifying new 
>types of resource messages conforming to Level 1.
>
>
>1.3.2 Level-2 EDXL-RM Message
>
>An XML 1.0 element is a conforming Level-2 EDXL-RM Message if and only if:
>a)      it meets all the requirements for a 
>Level-1 EDXL-RM Message specified in Section 
>5.3.1; and
>
>b)      its namespace name is 
>"urn:oasis:names:tc:emergency:EDXL:RM:1.0:msg"; 
>and
>
>c)      its content meets all the requirements 
>provided in the specific subsection of Section 3 
>(sections 3.4 to 3.19) corresponding to the 
>element's name (see also Section 5.3.1 item 
>(d)), including the Message Flow.
>NOTE   The conditions in (a) and (b) above imply 
>that the local name of the element is one of the 
>16 resource message type names specified in 
>sections 3.4 to 3.19 (see Section 5.3.1item (b)).
>
>1.4 Conformance as an EDXL-RM Message Producer
>
>1.4.1 Level-1 EDXL-RM Message Producer
>
>A software entity is a conforming Level-1 
>EDXL-RM Message Producer if and only if it is 
>constructed in such a way that any XML 1.0 
>element produced by it and present in a place in 
>which a conforming Level-1 EDXL-RM message is 
>expected (based on contextual information) is 
>indeed a conforming Level-1 EDXL-RM message 
>according to this standard.
>NOTE   The condition above can be satisfied in 
>many different ways. Here are some examples of 
>possible scenarios:
>-         a standard distribution protocol (say, 
>EDXL-DE) transfers EDXL-RM messages; a resource 
>consumer has sent an EDXL-RM request message to 
>a resource supplier which claims to be a 
>conforming EDXL-RM Message Producer, and has 
>received an EDXL-DE message which is therefore 
>expected to carry a conforming EDXL-RM Message;
>-         a local test environment has been set 
>up, and the application under test (which claims 
>to be a conforming EDXL-RM Message Producer) has 
>the ability to produce an EDXL-RM message and 
>write it to a file in a directory in response to 
>a request coming from the testing tool; the 
>testing tool has sent many requests to the 
>application under test and is now verifying all 
>the files present in the directory, which is 
>expected to contain only conforming 
>EDXL-RM Messages.
>
>1.4.2 Level-2 EDXL-RM Message Producer
>
>A software entity is a conforming Level-2 
>EDXL-RM Message Producer if and only if:
>a)      it meets all the requirements for a 
>Level-1 EDXL-RM Producer Message specified in 
>Section 5.4.1; and
>b)   it produces a conforming Level-2 EDXL-RM 
>Message when such a message is expected.
>NOTE   There is no requirement for a Level-2 
>EDXL-RM Message Producer to be able to produce 
>resource messages of all 16 resource message 
>types specified in sections 3.4 to 3.19.
>
>
>
>
>
>
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Thursday, April 17, 2008 11:52 AM
>To: Alessandro Triglia; 'Elysa Jones'; emergency@lists.oasis-open.org
>Subject: RE: [emergency] Use Case
>
>Good argument, and for now, I have to agree, but I'm reading the
>document Mary referred to see what it says about any possible
>difference or distinction between conformace in what is implemented
>and how much of a specification needs to be implemented.
>
>Cheers,
>Rex
>
>At 11:07 AM -0400 4/17/08, Alessandro Triglia wrote:
>  >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: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
>
>
>--
>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
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG.
>Version: 7.5.519 / Virus Database: 269.23.0/1381 
>- Release Date: 4/16/2008 9:34 AM
>


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