[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RM action items for Thursday meeting
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:
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.
--
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]