Hi Folks,
This will be the last note on the changes I'm making today, but I
wanted to make a somewhat surprisingly positive observation, too.
First I have slightly corrected the "Please Note" at the end of each
individual message's 3.X.2 Element Reference Model Section to be
more clear and correct: It now reads:
Please Note: the "IReport" element shown
below is an abstract type for the "Report" element contained in the
EDXLSituationReportRoot package and represents all elements in the
EDXLSituationReportRoot that may be needed for this or any other of
the five report types. "Report" declares the report type.
Meanwhile...
I've been digging into the details of what is always a dicey
proposition, translating between UML Models in EA and XML Schema to
make sure I have the relationships correct. I've been through this
particular flavor of headache with RM, so I was expecting a small
mountain of mismatches between the way we (I) have modeled this spec
in UML and how Don has captured it in XML Schema, so I was
pleasantly surprised when I loaded the XSD into EA and didn't find
that mountain.
We do have a few issues, but not the ones I was worried about.
The easy one for which I really don't have a strong preference is
naming convention. We used a somewhat more verbose approach in RM.
In RM we had to be verbose to deal with things like
RequestResourceDeploymentStatus. The only thing I think we need to
reconcile right now is "EDXLSituationReportRoot" and "SitRep." I
just wanted to check on it before I change it. It isn't very clear
that that "SitRep" is the set of elements used in every report,
whether required or optional. Of course we explain that, so I don't
know that it matters. I'd like to be pretty sure we're unlikely to
change back if I change it match the schema. Should we perhaps call
it "SitRepRoot"? "SitRepCore"? Something else?
In RM we put the made separate schemas for "EDXL-RMCommonResource"
and "EDXL-RMReference" which together outlined we we've called our
root--the elements for any of the 16 predefined and any user-defined
RM messages. Then, of necessity, we had individual schemas for each
predefined messages.
In the SitRep_Schema_DRAFT.xsd, the equivalent set of elements is
included in the single schema. It might be wise to poll some
implementers on whether they prefer it all in one file or having
the messages separated out. Doesn't make any big difference to me,
but if I was implementing it, I'd prefer to have the messages
separated out for ease of concentrating on them one at a time,
especially the ResponseResourceSummary (RRS) and the
ManagementReportingSummary (MRS). The other three are not all that
complex, although the CasualtyAndIllnessSummary (CIS) is a little
more complex.
For their own reasons CIS and RRS are more like each other than they
are like MRS, so it might make some sense to have them together. MRS
is big enough to be its own darn spec.
Both FieldObservation and SituationInformation are more general and
simple.
Please let me know about SitRepRoot. The rest just needs some
thought.