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:]
>Sent: Thursday, April 17, 2008 11:52 AM
>To: Alessandro Triglia; 'Elysa Jones';
>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:]
> >> Sent: Thursday, April 17, 2008 10:30
> >> To:
> >> 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
