Re: [lxml-dev] XMl Processing Instructions
Hi Noah, Noah Slater wrote:
If I understand your email correctly the behaviour I describe is not intentional and will be fixed shortly?
It has been fixed in the developer version, but there is not yet a release that has the fix.
Just to clarify - I can parse any file, but when I serialise I loose any processing instructions. This includes the <?xml ... ?> declaration.
I understood that.
This also happens with the ResultTree (?) when I transform using XSLT.
As an example, I use the DocBook XSLT stylesheets to transform DocBook XML. This can often set various things up with the processing instructions - character encoding being the most important.
When I perform these transformations using ElementTree I loose this information.
As a work around at the moment I am using lxml.etree to do the transformations using UTF-8 as the encoding. I am then using libxml2 and libxslt to transform the serialized document bytestream a second time with the only operation being converting from UTF-8 to another (variable) character encoding.
This feels quite hackish
Well, it /is/ hackish. :)
- and to be honest the whole point of me moving to lxml was because I find the libxml2 and libxslt bindings hateful.
That's one of the main reasons that drive us in writing lxml - right after users saying "thank you, it's great and helps us do stuff!" :)
To summarise, in an ideal world I would like to be able to transform a document using XSLT specifying an encoding at transformation time and have the ResultTree serialise with all processing instructions intact. Additionally I would like to be able to access these programmatically - which I don't think is possible at the moment.
That's also a feature of the developer version that will eventually become lxml 1.0. See the 'docinfo' feature described here: http://codespeak.net/svn/lxml/trunk/doc/api.txt See here for a complete list of changes since 0.9.2: http://codespeak.net/svn/lxml/trunk/CHANGES.txt
I hope all this makes sense.
It does. Thanks for the report. Please use the current SVN trunk version for now, lxml 1.0 is expected to be released this month. See http://codespeak.net/lxml/installation.html and the bottom of the download section in http://codespeak.net/lxml/ on how to check it out of the subversion repository and compile it. Stefan
Hi Stefan,
To summarise, in an ideal world I would like to be able to transform a document using XSLT specifying an encoding at transformation time and have the ResultTree serialise with all processing instructions intact. Additionally I would like to be able to access these programmatically - which I don't think is possible at the moment.
That's also a feature of the developer version that will eventually become lxml 1.0. See the 'docinfo' feature described here: http://codespeak.net/svn/lxml/trunk/doc/api.txt
Sorry if I am being a pain, but can I just clarify what you meant by this. Were you also indicating that programmatic access to PIs would be available in lxml 1.0? If not, is this on the time line? Thanks so much, Noah -- "Creativity can be a social contribution, but only in so far as society is free to use the results." - R. Stallman
Hi Noah, Noah Slater schrieb:
To summarise, in an ideal world I would like to be able to transform a document using XSLT specifying an encoding at transformation time and have the ResultTree serialise with all processing instructions intact. Additionally I would like to be able to access these programmatically - which I don't think is possible at the moment.
That's also a feature of the developer version that will eventually become lxml 1.0. See the 'docinfo' feature described here: http://codespeak.net/svn/lxml/trunk/doc/api.txt
Sorry if I am being a pain, but can I just clarify what you meant by this. Were you also indicating that programmatic access to PIs would be available in lxml 1.0?
No. All functionality of 1.0 is described in the documentation and already available in 1.0.beta.
If not, is this on the time line?
No. Feel free to provide a patch that implements ProcessingInstruction in an ET compatible way. Stefan
participants (2)
-
Noah Slater
-
Stefan Behnel