You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Nokogiri tries to figure out namespaces after node reparenting via our homebrewed function node.c:relink_namespace(), however what we're doing there is probably not quite right as evidenced by the number of issues as well as the commentary on a few PRs, notably #2495 and #2310.
Recently I discovered that libxml2 has a method, xmlReconciliateNs(), which seems to do what we want (from a brief reading).
This issue is to explore using xmlReconciliateNs() with careful attention paid to:
does this fix some of the issues reported
does this break existing tests
does this break downstream consumers of Nokogiri
The text was updated successfully, but these errors were encountered:
@nwellnhof Thanks, I just came back to this issue to link to your comment from #613.
It's still something I'd like to explore -- I'm not at all convinced that what Nokogiri is doing today is better. And if I discover edge cases I might be able to help contribute to an updated/new implementation.
Another option, but probably even less tested, is xmlDOMWrapAdoptNode. This function seems to implement W3C DOM Namespace Normalization and should be called before moving a node. There's also xmlDOMWrapReconcileNamespaces.
Currently Nokogiri tries to figure out namespaces after node reparenting via our homebrewed function
node.c:relink_namespace()
, however what we're doing there is probably not quite right as evidenced by the number of issues as well as the commentary on a few PRs, notably #2495 and #2310.Recently I discovered that libxml2 has a method,
xmlReconciliateNs()
, which seems to do what we want (from a brief reading).This issue is to explore using
xmlReconciliateNs()
with careful attention paid to:The text was updated successfully, but these errors were encountered: