MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] XML Content namespacing
On 8 Dec 2005, at 12:21, Ellis, David wrote: The use of partial encryption of elements might work on medium security industrial applications, but for pre event sensor and intelligence-related messaging activity for national security, bulk encryption of the entire embeddedXMLContent will undoubtedly be required.�
My proposal allows this. The examples I gave included non-encrypted elements to show how we can support such payloads much�simpler and efficiently. I am not a convinced we need to make CAP �default namespace copying� as such an important requirement.� The release of CAP 1.1 and in the future resource management and sensor systems payloads will most like require applications to use XSLT processes to create new messages and adding prefix element names during transformation would be trivial� (CAP1.0:alert , CAP1.1:alert etc.
This was just an example of default namespacing. You can use any relevant XML Namespace for the payload, with or without namespace prefixes. Since this is all XML, then this support is mandatory and fundamental for any system creating/parsing EDXL elements.
�Changes in this method now are significant and would break many prototype EDXL DE applications created during public comment of the EDXL Distribution Element.
*Any* change we make will "break" early implementations of EDXL-DE. That is a fact of life in the process of standardisation. The Committee Draft makes that very clear [1]. If we make "Substantive Changes" then we can go out for more public comments.�
Cheers...� Renato Iannella National ICT Australia (NICTA)
[1] <http://www.oasis-open.org/committees/process.php#3.2>
--------------------------------------------------------------------------
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]