We don't have a requirement for pure inclusive C14N, but we have some WSS interop scenarios where all the prefixes are listed in the InclusiveNamespacePrefixList , so it kind of becomes Inclusive C14N. Because of this requirement to support exclusive C14N with some inclusive prefixes, we need to distinguish between namespaces that are explicitly declared and those that inherited from nodes outside the document subset. So the optimization of the input tree having all namespaces, and none extra would not really work. Pratik Scott Cantor wrote: > Pratik Datta wrote on 2009-03-30: > >> E.g. consider a signed SAML assertion. The declaration for the saml >> namespace may be in the <saml:Assertion> itself, or in the >> <wsse:Security> ancestor element. Also the wsse:Security element may >> include other namespace declaration that are not used inside the SAML >> assertion. The saml assertion should be movable from one message to >> another without breaking the signature. >> >> So we need to support all the namespace complexity with Exclusive C14N, >> Exclusive C14N with InclusivePrefixList and Inclusive. >> > > Just curious, is there any actual use case for Inclusive once you've been > forced to support Exclusive? > > Separate question...is there an optimization possible if one were to require > that the input tree (or trees) was already carrying the right set of > namespace declarations (and none that shouldn't be there)? > > -- Scott > > > >
Received on Monday, 30 March 2009 22:10:22 UTC