libxml evening
Saturday, May 7th, 2005Today I’ve submitted a bug to libxml, written to the libxml mailing list about wish items on the documentation, and asked about xpath and the document order in libxml.
Today I’ve submitted a bug to libxml, written to the libxml mailing list about wish items on the documentation, and asked about xpath and the document order in libxml.
Yesterday I updated libxml2 and xsltproc from CVS and got a coredump. I am very scared because I can’t produce a test case and I think that the problem is on libxml’s side.
I found a non-obvious issue in the Namespace Recommendation and fixed my converter. Then I decided to look at other popular de-facto stanadrd tools. They are buggy. So I don’t understand why I work so hard to make my program as correct as possible.
XML namespaces are an invention from the evil. Two harmlessly looking messages in one of the scripts evolved to two hard debug sessions. Fortunately, I managed to fix the both bugs.
The conversion from the libxml nodes to SXML works, the reverse conversion works too. Meanwhile, the function “x:eval” which was planned for the third milestone is also implemented. Now I’m going to review all my remarks, fix my bugs and submit bugs to the libxml team.
Conversion of the attribute nodes seems working, although with some glitches. And I traditionally mention namespaces. I decided to have holes in ns processing in the first version.
SXML to XML conversion of attribute nodes is becaming a trouble. I’ve fixed several initially unnoticed issues and found more items to check.
Namespaces are still working, xml node of the type “document” is now handled correctly, XSLT XPath functions are activated. To finish with the libxml to sxml conversion, support of the top-level attribute nodes and result tree fragments should be added.
One of the use cases for XPath over legacy data is structured FrameMaker (FrameMaker+SGML). The structure is in fact XML, that’s good. But the only interface to this XML is something tree-like which is worse than DOM.
Adding variables to XPath was a simple task. But when I was testing it, I had to switch to testing the Scheme function “x:current” (former name “x:current-node”) and then found an essential problem with the namespaces.
I’m slowly and painfully writing a paper for the Generative Programming and Component Engineering (GPCE’05) conference. I hate my writing which should be thrown away and rewritten from scratch. But deadline is near, and today was a firm day for submitting abstracts.
Article isn’t writing. Although, in general, I have ideas what to write, the actual writing is painfully slow. Today I’ve only finish a section, and I feel I’ll rewrite it somewhen.
I’m writing a paper (not for GTTSE2005 as the previous entry may suggest). Here is a bit of the text written today.
Just have received a very nice notification: “The registration form you submitted has been evaluated, and we are happy to inform you that you have been ACCEPTED to participate in the Summer School on Generative and Transformational Techniques in Software Engineering (GTTSE 2005).”
I’ve just stumbled upon a new article at xml.com: Directory Trees to Document Trees. I’ve posted a comment to the article and dropped a note to the author.
Implementation of the “x:value-of” function evolved to a quest. There are many questions, and in order to find answers, I have to dig in the source code of libxml and libxslt.
All this time I’ve subconsciously been ignoring a big namespace-related problem. I’m afraid the correct solution slows down the conversion between XML and SXML, and that I have to use the correct solution.
Thinking about testing XML to SXML conversion to pass the second milestone, I found out that I need functionality that was planned for the future. So I temporary switched to the phase three.