[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: EDXL-RM Statement Of Use
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.
The two following conformance targets are defined in order to support the specification of conformance to this standard:
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.
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:
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
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;
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
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
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.
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
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.
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.
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.
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.
>> -----Original Message-----
>> From: Elysa Jones [mailto:firstname.lastname@example.org]
>> Sent: Thursday, April 17, 2008 10:30
>> To: email@example.com
>> 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 >
>> 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.
>> Elysa Jones
>> Chair, OASIS EM-TC
>> 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
Starbourne Communications Design
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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]