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: FW: [emergency] keyXMLContent Versus embeddedXMLContent

Title: [emergency] keyXMLContent Versus embeddedXMLContent
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.    
David E. Ellis
Information Management Architect
(505) 844-6697

From: Renato Iannella [mailto:renato@nicta.com.au]
Sent: Tue 11/22/2005 8:41 PM
To: Emergency_Mgt_TC TC
Subject: [emergency] keyXMLContent Versus embeddedXMLContent

I must admit, I am confused as why we need the <keyXMLContent> element
since all the elements will be repeated in the <embeddedXMLContent>?

The DE does not define which elements (since it can't) that are 

You then need to ask, if two systems agree to put <aaa:foo> element 
in the <keyXMLContent>
element, then what benefit is there to just saying that the <aaa:foo> 
element is in the
<embeddedXMLContent> element (which it always will be)...The 
processor will still need to read
and validate all elements.

Alternatively, if one system puts  <aaa:foo> element in the 
<keyXMLContent> element
(and nobody else understands this) then what are recipient systems 
supposed to do with that "key" element?

(I am assuming the DE is not supposed to make any assumptions on the 

Any enlightenments?

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.

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

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