Re: serialization and xml wrapping

On Thursday 26 September 2002 03:18 pm, merlin wrote:
> So, the example doesn't follow our implicit recommendation
> of using c14n, but instead relies on inheriting namespace
> information from the surrounding document.
>
> Does this make sense?

It makes some sense, but I'm still not sure about the interplay between 
these steps:
1. We should make the text less confusing... 4.3.3 Starts off by saying, 
"When serializing an XML fragment for subsequent wrapping and parsing, 
serialization of the namespace axis should be changed as follows". This 
makes it sound like it's part of the decryption process. If so, exactly 
which step of 4.3.{1,2} is this relevant? (Text Wrapping is explicitly 
called in 4.3.1 and 4.3.2)  There's probably no hook in 4.3.2 because it's 
a nodeset sorta-based replacement mechanism. Whereas the one in the 
Decryption transform is a much more specific octet based canonicalization 
and replace based mechanism. Is that right? If so, how do we make that more 
clear? Be more explicit that 4.3.2 is a node-set based mechanism, but 4.3.3 
only applies to mechanisms like those in the Decryption Transform?
2. What about Ari's comment that in the Decryption Transform, decryptXML(N, 
E) only emits xmlns="" when there's no prefix *and* URI. (Or does this go 
away with the proper understanding of the above? <smile/>)


> >Further: [3] indicates, for Step 2 of  decryptXML(N, E), that: "A
> > namespace declaration xmlns="" MUST be emitted with every apex element
> > that has no namespace prefix and URI as described in Serializing XML
> > [XML-Encryption, section 4.3.3]". Firstly, we're talking about the apex
> > elements in a node-set, which might include namespace nodes for the
> > default namespace inherited from the dummy element in prior
> > wrapping/parsing -- this means that an element without a namespace
> > prefix is not necessarily without a namespace, and emitting xmlns=""
> > would conflict with emission of the namespace node in the node-set.

Received on Thursday, 26 September 2002 17:57:30 UTC