[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
Hi Tim, No problem – I agree that we need to
nail things down, and wasn’t feeling pressured. I just didn’t
want to promise to have everything done when I was unsure whether it was
possible! I have just sent a rough draft, but the
schemas & examples will no doubt have to change again based on the
decisions we make tomorrow! Talk to you then… Karen. From:
Timothy Grapes [mailto:tgrapes@evotecinc.com] 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]