OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Another Note: IReport rewording


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]