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.