[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XML Content namespacing
In today's teleconf, I promised to propose a solution to the namespacing issues dealing with the two children elements of the <xmlContent> element, namely <keyXMLContent> and <embeddedXMLContent> (as there was lots of discussion on this point). The problem arises since there maybe XML namespaces used in the <embeddedXMLContent> that you wish to also use in the <keyXMLContent>, or, in some cases, the <embeddedXMLContent> is being encrypted and you don't expose the XML namespaces. Part of the problem is that we have two child elements to deal with, and one (possibly more) namespace(s) to support. The reason for having two child elements was to support the use case of the xml content being encrypted, but still having some (non critical) elements exposed in clear text. However, there is a way we in which we can use one (and only one) element for xml content that can support this use case. Consider the below example, where the xml payload is all expressed within the <xmlContent> element (assume there is no <keyXMLContent>and <embeddedXMLContent> children elements. The payload is a CAP message that is encrypted (ie all the stuff between the <EncryptedData> elements) and three CAP elements at the beginning of the payload that you want to be open and readable. <ed:xmlContent> <alert xmlns = "urn:oasis:names:tc:emergency:cap:1.1"> <identifier>KAR0-0306112239-SW</identifier> <source>SW</source> <scope>Public</scope> </alert> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#"> ----encrypted CAP elements are here-- </EncryptedData> <ed:xmlContent> In this example, we also show the use of XML namespace defaulting. That is, the CAP and XML Encryption namespace prefixes are not used - although you can - and are default to the enclosing elements. You could also express the above with explicit XML namespaces as: <ed:xmlContent> <cap:alert xmlns:cap= "urn:oasis:names:tc:emergency:cap:1.1"> <cap:identifier>KAR0-0306112239-SW</cap:identifier> <cap:source>SW</cap:source> <cap:scope>Public</cap:scope> </cap:alert> <ec:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:ec="http://www.w3.org/2001/04/xmlenc#"> ----encrypted CAP elements are here-- </ec:EncryptedData> <ed:xmlContent> So, my proposal would be to simplify the specification by using one element <xmlContent> for all XML payloads. You can use default and/or explicit XML Namespace prefixes. And since you can include any XML, you can expose any encrypted XML in the same element. Cheers... Renato Iannella National ICT Australia (NICTA)
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]