Context for this issue was https://lists.oasis-open.org/archives/saml-dev/201909/threads.html

The gist I guess is that this collides with the minimal handling of xml:lang in any of the SP's code in theory, but I don't think it does in practice at the higher layers.

Since setting xml:lang="" actually means to unset it, the theoretical meaning is that it would force the lang setting to be inherited from the parent XML. This is impossible in SAML constructs because they don't have any parents that allow it to be set, so unsetting it is equivalent to not having it in all the cases that are explicitly handled.

That's a convenient accident, but I think it does mean that the code is actually producing the right result today on the consuming side by treating it as not set.

One can argue the generation side should be better, but I don't think it's a warranted change to try and do that since it would require invasive analysis and rework of the existing manual validators that detect missing content and distinguishing between empty and null, which they don't have to do today.

So we get nothing, and we risk null pointer crashes all over the code.

So I'm leaving open as unfixed, but for the record, the code does not allow empty lang to be created and will treat incoming empty strings as null as a general matter.

The root of the bug appears to be that XMLString::equals in Xerces treats empty and null as equal, which means trying to "set" the empty string is treated as no-change from it being null to start with, and nothing happens.

On the generation side, it does not preserve the empty lang attribute, which was my supposition. The code for metadata verification was changed so that roundtripping probably still works since it spools the bytes to disk rather than an actual reparse of the serialized copy of the DOM.

I think this is in fact working, but I think the empty string may be an edge case that's worth just testing to understand how it behaves.