[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-msg] RE: RM action items for Thursday meeting
|
Karen, I know you will do what you can – my
message sounded like I am pressuring you and that’s not my intent.
You have and continue to go over and above in this effort. We’re
just reached a time when we need to nail down the spec, get it through the TC
and into public comment, and then clean up outstanding issues. Please let
me know if there is anything I can help with. I also vote for the 2nd approach
and am OK with renaming to EDXLResourceMessage. In addition to the points
you make, this also retains the ability by any implementer to use the overall
RM reference schema as the basis to constrain and create additional messages if
requirements dictate. As long as the integrity of the reference schema is
adhered to, this wouldn’t be an issue and the TC could even consider addition
of other Resource Messages to later versions of the spec. Thanks, Tim From: Aymond,
Patti [mailto:Patti.Aymond@iem.com] Karen, I like the 2nd
approach, too. I also agree on renaming “ResourceMessage” to
“EDXLResourceMessage”. Patti Patti Iles
Aymond, PhD 8555
United From: Karen
Robinson [mailto:Karen.Robinson@nicta.com.au] Hi Tim et al, I’ll do
my best with my action item - it’s a pretty big job, however. I may
just be able to finish a first draft of all the schemas and message examples,
but I won’t have time to check over them all as well. In any case,
I will send you what I have, and I will be on the call. There is still
one issue that I wanted to discuss with the group, however, which is related to
namespaces & top-level elements. The question is whether to use one
namespace for all of the message schemas, or to have a separate namespace for
each message type. In the first
case, we need a different top-level element for each message type. This
is how the current schemas in the spec are done – e.g., in the reference
schema, the top-level element is “EDXL_RM_Reference”, in the
“Request Resource” schema it is “RequestResource”, etc.
There are two namespaces – the types and elements in the CommonTypes
schema belong to the “urn:oasis:names:tc:emergency:EDXL:RM:1.0”
namespace, while all other elements belong to the
“urn:oasis:names:tc:emergency:resource:1.0” namespace. This approach
is fine, but it means that if you want to validate a message against the
reference schema, you have to modify the top-level element first. In my
opinion, validating against the reference schema instead of a specific message
schema is a valid thing to want to do, and we should support it (otherwise,
there is not much point having a generic schema). The other
approach is where we define a namespace for each message type. All
message types can then use the same top-level element (e.g.,
“EDXLResourceMessage”), and all should be able to validate against
the reference schema. This is how I was initially developing the schemas
prior to the face-to-face. The namespace for the reference schema was
“urn:oasis:names:tc:emergency:EDXL:RM:1.0:Reference”, while the
namespaces for individual message schemas were
“urn:oasis:names:tc:emergency:EDXL:RM:1.0:RequestResource”,
“urn:oasis:names:tc:emergency:EDXL:RM:1.0:ResponseToRequestResource”,
etc. For the
record, the second approach is my preferred one. My question is:
was there a formal decision taken at the face-to-face about which approach to
take, and the most appropriate name(s) for top-level elements and
namespaces? If not, the group should probably decide on these things now
– and the top-level element(s) should presumably be properly defined in
the Data Dictionary along with all the other elements. By the way, the
element reference models, the tables in the message sections and the title of
Section 4.1.1 all seem to imply that the top-level element is always called
“ResourceMessage”. My vote would be to name this element
“EDXLResourceMessage”, as this is more consistent with the naming
of the top-level element in EDXL-DE – “EDXLDistribution”. Sorry for the
excessively long email! J Karen. From: Timothy
Grapes [mailto:tgrapes@evotecinc.com] Hi Karen, We convened a short conference call
today on RM. If possible for everyone with actions, we would like to
convene another call this Thursday with the objective of finalizing the RM spec
– at least to the point where we would feel confident to request a
special EM-TC call the following week to submit the spec requesting it move
into 60-day comment. The group agreed to adopt the
changes stated in your email for Originating and Preceding message ID.
Our understanding is that you have taken on vetting of the individual message
schema instances and message examples. Can you make a Thursday 4:00 PM ET
call, and do you feel it is reasonable to have those sections ready? You’ll see an OASIS meeting
request and minutes following. Please let us know what you think. Tim Grapes IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: --
-- -- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]