On 05/11/2013 11:32 PM, Daniel Veillard wrote:
On Sat, May 11, 2013 at 12:17:57AM -0400, Eric Levy wrote:Hello, I am struggling to understand how libxml2 is meant to handle namespaces. Most recently, I created an in-memory document using the public API that causes libxslt to hang on xlstCopyNamespaceList() when I call xsltApplyStylesheet(). I am developing a small application that has a feature similar to XInclude. An element in one document causes the inclusion of a subtree of another document. I use the xmlCopyNode() routine to obtain a subtree suitable for being inserted into another document, and I had hoped that the library layer handles namespaces transparently, but it seems not so. I should say that I also tried xmlDocCopyNode(), but I saw no difference in behavior. I observe that the ns field of xmlNode is only populated if the node has a namespace declaration in the original document. Further, theThat is completely normal. if the element had no namespace in the source document, why should libxml2 'invent' a namespace for it.resulting document I created is corrupt, as evidenced from the observation that when it is used as a stylesheet in a transformation, the transformation method never returns, but rather goes into xsltCopyNamespaceList() indefinitely. Perhaps someone can address the following issues: 1) In some xmlDoc, how do I determine the namespace of a particular xmlNode, following XML rules for inheritance?Check that the type of the node is Element or Attribute, then after casting to an xmlAttrPtr is needed the ns points to the namespace declaration, hosted either on the local Element or one of its ancestors.
Thanks for the reply. Actually, I see now that xmlSearchNs() is provided to do exactly what you said. Please understand that I find it hard to deduce the correct use of the library from the brief documentation. However, I must say that once I do understand the API, I find it very intuitive and well-designed.
2) How do I copy xmlNode instances across documents so as to correct for namespaces?xmlStaticCopyNode() which is called by xmlCopyNode() tries to do the right thing:
Yes, after further testing I see that the namespaces are copied. However, because I had an application that combines both node copying and transformations, I was confused by the below issue.
/* * Humm, we are copying an element whose namespace is * defined * out of the new tree scope. Search it in the original tree * and add it at the top of the new tree */3) Is the behavior I described a bug in the library, or my misuse of it?Not completely sure.
I was able to isolate the problem, and I would have to call it a bug. I found that if a stylesheet 1) has a namespace-alias element mapping prefix "n" to no prefix, AND 2) has an element with the same namespace prefix, "n", in one of the templates "t", then applying the stylesheet to a document that matches "t" will hang. I have attached a test case. There is no C code. Just toss the files into xsltproc to see the problem. I also provided my version information below.
I'm not completely certain what should happen under these circumstances, but I can say the the operation should return promptly, either with an error or with a result.
Using libxml 20706, libxslt 10126 and libexslt 815 xsltproc was compiled against libxml 20706, libxslt 10126 and libexslt 815 libxslt 10126 was compiled against libxml 20706 libexslt 815 was compiled against libxml 20706
Daniel
Attachment:
bar.xslt
Description: application/xslt
Attachment:
foo.xml
Description: Text Data