attributes are not so simple

SXML to XML conversion of attribute nodes is becaming a trouble. I've fixed several initially unnoticed issues and found more items to check.

The first problem was the another side of the benefits. The uniform representation of elements and attributes makes impossible to distinguish between them. The code

<s:scheme>(x:deep-copy (x:eval "smth/.../smth/@aname"))</s:scheme>

was returning

(aname "some avalue")

which is the representation for

<aname>some avalue</aname>

Now the problem is fixed and the Scheme code above returns

(@ (aname "some avalue"))

There are still serious issues;

* what's if the attribute name is in some namespaces,
* what's if the nodeset has several attributes (we mustn't return several @-nodes, but only one (or maybe we can)),
* what's if the nodeset has several attributes with the same name,
* etc.

The second problem was a coredump. Having some time spent on it, I traced to the code spot which didn't look suspicious, but caused some memory reference problems. It was usage of the functions "xmlCopyNode" and "xmlAddChild". When applied to an attribute node, "xmlCopyNode" doesn't make a copy of its name. The function "xmlAddChild" adds such node to an XML tree, so the tree has two links to the same memory block. When document is freed, the memory is freed twice, causing coredump. It looks like a bug in libxml (or in my approach), but I failed to demonstrated it on a small sample, so I'll not report the problem to libxml team. And now my code contains a wonderful example of mystic code:

if (XML_ATTRIBUTE_NODE == node->type) {
  node->name = xmlStrdup(node->name);
}
Categories: Generative XML

Updated: