I’m not sure whether that’s an inconsistency or deliberate. In EDXL to date it’s been a deliberate decision. In context of emergencies and disasters, all payloads need a routing header of some kind. When discussing payload requirements, the practitioners consistently discuss information that is fundamentally related to the routing of the payload, such as DateTimeSent. Any payload can be stripped and used on their own after routing.
I’m not sure I see an example in EDXL where that’s inconsistent since direction set following CAP (integrated connection to content). Discussions are moving forward where CAP may continue independent routing as well as/or encapsulated in the DE. The deliberate decision after CAP 1.0 and direction forward was 1- Every payload needs some sort of routing header, 2- The DE was designed to be that common routing header in the Emergency/disaster space, 3- It didn’t make sense to build routing capabilities into every payload, and 4- Don’t duplicate a concept in the payload if it functionally fits in the ( or in “a”) routing header. It’s also been recognized that DE is not a “one size fits all”. It fits a specific need, where Lex/Ulex and (forget the other one) meet other more secure known system to system needs.
Now, that direction can be changed if the TC sees fit, and desires these payloads to stand-alone regardless of the routing header/mechanism used, and assuming that other routing headers do not address example requirements like this one.
But the only murky area for me till now has been around the additional general spec statement that “other” routing headers may be used IF they conform to the minimum requirements of that particular payload for routing.
Thanks,
Tim Grapes
Evotec
703-304-4829
"The problem is not that there are problems. The problem is expecting otherwise and thinking that having problems is a problem." - Theodore Rubin
Re the following: Action item: EDXL-DE contains the “dateTimeSent” (SEE highlighted excerpt below). Are these equal and can this requirement be met through the DE? If so, refer to this requirement in the “routing section” of the spec and state that the DE “dateTimeSent” will be used to meet this requirement.
This is back to the fundamental question of how to use the DE. In RM we deliberately forced a level of coupling between the DE (or an alternative routing wrapper????) and its content. The forces the two to be kept together to provide full clarity. OTOH CAP and NIEM IEPs are entirely independent of the DE. They can be routed using a DE, but also stripped and used on their own after routing. The difficulty arises when a single DE is used with multiple content items if some can be stripped and some cannot. The appears to be an inconsistency in our design. Full encapsulation or content or integrated connection to content. This is a DE philosophical question that seems to be applied differently for different message content types. Which is right?
All,
Edits now include;
"Routing header" element requirements
SitRep "Root element"
ReportType "Situation Information"
Clarified issues, resolved duplicates and added elements where appropriate
- some require model / design work (e.g. "paired" elements.
Open questions or final wording needed for yellow highlights.
Have a good weekend - remember that I am on travel / in meetings and must
miss the next SitRep meeting. Will continue working this on travel.
Tim
-- Tim Grapes
The document revision named EDXL-SitRep Data Dictionary V3.1
(EDXL-SitRep-Data-Dictionary_OASIS-DraftV3.1_09-03-2010.doc) has been
submitted by Tim Grapes to the EM Messages and Notification SC document
repository. This document is revision #1 of
EDXL-SitRep-Data-Dictionary_OASIS-DraftV3.0_08-26-2010.doc.
Document Description:
View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=39222
Download Document:
http://www.oasis-open.org/committees/download.php/39222/EDXL-SitRep-Data-Dictionary_OASIS-DraftV3.1_09-03-2010.doc
Revision:
This document is revision #1 of
EDXL-SitRep-Data-Dictionary_OASIS-DraftV3.0_08-26-2010.doc. The document
details page referenced above will show the complete revision history.
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration