[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. Thanks, Tim 1.1 Conformance
Targets
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. 1.2 Conformance
Levels
The two following conformance levels are defined
for 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
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 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 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----- 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 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]