OpenSAML and Apache Santuario (xmlsec) 1.5.1

[Cantor, Scott]

On 4/13/12 6:09 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>I just did a simple test using the DOM API.  Turns out, attribute
>ID-ness does not persist across adopting the Element into a new
>Document. Or at least, Document getElementById does not work on the new
>Document after adoption.  That's a bit surprising to me, I don't know if
>that is a bug in Xerces or the intended behavior.

I'll give them the benefit of the doubt and guess that most of those
justifications essentially predate any acceptance of IDness outside of
DTDs. There are really two completely opposed ways of looking at XML and
IDs, and one of them is completely incompatible with XML Signature.
Unfortunately, that's the view the rest of the XML world takes.

FWIW, I don't *think* Xerces-C behaves this way, but I don't know for sure.

>For various reasons, including the cost of adoption, I've often thought
>that that unconditional new Document creation and adoption in the
>marshallers was a bit sketchy.  I believe C+ OpenSAML doesn't
>unconditionally do that, it first checks whether the XMLObject already
>has a cached DOM.

Yes, marshalling in C++ is a no-op if the DOM exists.

>  On the other hand, there could be problems with not
>doing it in some cases, such as when you want to make the cached tree
>hierarchy consistent again (e.g. your case of wanted to replace
>Encrypted* things with the corresponding decrypted instance).

If you replace an element like that in the tree, I throw away the cached
DOM everywhere above the change.

-- Scott