Title: [emergency] keyXMLContent Versus embeddedXMLContent
All
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:]
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
repeated.
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
payload...)
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
