[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: EDXL-RM Statement Of Use
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]