I'll re-iterate, as long as you use "official" LibXML2 API, it should work just fine. Or there is a bug in the LibXML2 code :)
Aleksey On 3/21/14, 1:06 AM, Frank Gross wrote: > Ok, I understand the need of speed, but there is still something that > worries me. This means that the Canonicalization process depends then on > the way the XML document is in memory. For instance, if I load a XML > document from disk and canonicalize it, or build the same document in > memory from scratch with node built maybe from copy or clone of another > document in memory, the Canonicalization result can be different, even > if document saved on disk would be the same. > > But ok, I will fix it in my code > > Thanks a lot, > Frank > > > Le 20/03/2014 15:04, Aleksey Sanin a écrit : >> The tradeoff here is speed. Again, if you are using standard LibXML2 >> API then everything will work as expected. I have no idea why do you >> need to create new xmlNsPtr objects - this sounds like a waste of >> CPU/memory to me but you might have your reasons. But this also breaks >> a few assumptions on how LibXML2 represents the DOM tree in memory >> and you are on your own in this case. >> >> Aleksey >> >> On 3/20/14, 1:26 AM, Frank Gross wrote: >>> Hi, >>> >>> Actually, I have an additional layer to emulate DOM compliant API over >>> libxml. In that layer, I have a global list of xmlNsPtr for all >>> namespaces encountered by the nodes (and referenced in node->ns) of a >>> single XML document. And for each namespace definition (xmlns:xxx) set >>> on a node, a new xmlNsPtr is created and referenced in node->nsDef. So >>> during canonicalization process, when a node looks for a parent >>> namespace definition via xmlSearchNs, it can happen that the xmlNsPtr >>> reference from the node is different from the parent node->nsDef , even >>> if the href and prefix value are the same. Then of course simple pointer >>> comparison doesn't work. So I was asking myself if such situation cannot >>> happen to other people, and maybe change the pointer comparison because >>> depending on how people build and manipulate the document, the test is >>> not always accurate. >>> >>> >>> Frank >>> >>> >>> Le 20/03/2014 03:16, Aleksey Sanin a écrit : >>>> How do you manipulate the XML tree? If you are using "official" LibXML2 >>>> function then I believe this code should work just fine unless there is >>>> a bug in the strings dictionary. >>>> >>>> Aleksey >>>> >>>> On 3/12/14, 10:28 AM, Frank Gross wrote: >>>>> Hi, >>>>> >>>>> I'm getting some trouble to verify a XML signature because the >>>>> xmlC14NProcessNamespacesAxis() function does a xmlNsPtr pointer >>>>> comparison to decide whether a sub node belongs to the same default >>>>> namespace as an ancestor. But if the sub node has been manipulated by >>>>> program (in my case) to point to another xmlNsPtr with same values, >>>>> the >>>>> canonicalization process breaks. Wouldn't it be better to check the >>>>> namespace href values instead as in following patch ? >>>>> >>>>> diff --git a/lib-xmlsoft-libxml2/src/c14n.c >>>>> b/lib-xmlsoft-libxml2/src/c14n.c >>>>> index 9c3cad2..f73e709 100644 >>>>> --- a/lib-xmlsoft-libxml2/src/c14n.c >>>>> +++ b/lib-xmlsoft-libxml2/src/c14n.c >>>>> @@ -623,7 +623,7 @@ xmlC14NProcessNamespacesAxis(xmlC14NCtxPtr ctx, >>>>> xmlNodePtr cur, int visible) >>>>> for(ns = n->nsDef; ns != NULL; ns = ns->next) { >>>>> tmp = xmlSearchNs(cur->doc, cur, ns->prefix); >>>>> >>>>> - if((tmp == ns) && !xmlC14NIsXmlNs(ns) && >>>>> xmlC14NIsVisible(ctx, >>>>> ns, cur)) { >>>>> + if((xmlStrEqual(tmp->href,ns->href)) && >>>>> (xmlStrEqual(tmp->prefix,ns->prefix)) && !xmlC14NIsXmlNs(ns) && >>>>> xmlC14NIsVisible(ctx, ns, cur)) { >>>>> already_rendered = >>>>> xmlC14NVisibleNsStackFind(ctx->ns_rendered, >>>>> ns); >>>>> if(visible) { >>>>> xmlC14NVisibleNsStackAdd(ctx->ns_rendered, ns, >>>>> cur); >>>>> >>>>> Regards, >>>>> Frank >>>>> > _______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml