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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: Re: [emergency] keyXMLContent Versus embeddedXMLContent

On 23 Nov 2005, at 14:33, Ellis, David wrote:

I am having great concern that we have lost the concept of encrypted payload for the embeddedXMLContent and the reason for the XPathable values to use in a Publish-Subscribe distribution model.  I appreciate the data reuse and normalization attempts for a application to application approach for point-to-point distribution. I am working on a scalable near-real time national distribution system for saving lives.  The keyXMLContent provides a deterministic point for matching non-sensitive values of the embeddedXMLContent for distribution.    

I am assuming, and again, I could be wrong, was that the DE's role is for distribution.
Hence, all the DE elements are used for that purpose. The <contentObject>s are intended
for the "end user" recipient(s). That is, any DE processor in the chain will be parsing the DE elements
to make decisions on routing. When it gets to the recipients, they will look at the contentObject and
do whatever they are supposed to do.

The reason for this is that we (at the DE level) have no knowledge of what is inside the <contentObject>s
and hence, we cannot make any reference to them in the specification that may influence distribution.
Of course, this does not stop someone from building a CAP/EDXL-DE processor that understands both.
But from the EDXL-DE specs point-of-view, we are only limited to the elements we define (and control).

Cheers...  Renato Iannella
National ICT Australia (NICTA)

This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.

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