[lxml-dev] Adding a Stylesheet PI when creating new XML documents

[Stefan Behnel]

Hi Lee,

Lee Brown wrote:
> I think the prependPI() is slightly better, as it is reminiscent of the append()
> method.

I personally liked the "addToTree()" method better as it allows us to
accompany it with a "copyToTree()" method that would not remove the PI from
its current location. Maybe "prependToTree()" and "prependCopyToTree()" would
be even more descriptive names.


> Here's a silly thought:
> 
> Couldn't we just save any PIs preceeding the root element as members of docinfo?
> That's where the doctype, xml version, and other "pre-root" stuff lives.
> Doesn't "tree.docinfo.stylesheet" or "tree.docinfo.PI['stylesheet']" make more
> sense than the way we're doing it now?
> 
> (And wouldn't it have been nice if I'd thought of this several months ago?)

Not that silly at all, and not too late either, since we do not yet have an
API for this (apart from the generic 'getprevious()' method).

So, regarding your proposal: it will not quite work as nothing prevents an XML
document from having 20 processing instructions of the same type. The meme
above sort of suggests that there can be only one (note that we are talking
about etree here, not objectify, which has a very different look-and-feel).

Is there any obvious way that would allow us to handle the normal case of zero
or one PIs per type as nicely as possible, while allowing us to deal with the
possible case of having an arbitrary number of them?

I mean, since PIs can be accessed with the normal API, the main problem we are
facing is that we currently cannot append or prepend siblings - only children.
 And the API is pretty much geared towards child handling (because that's how
things work in ET), which is usually enough - except for document level
processing instructions that *are* siblings.

I already said it was time to think a bit more about the docinfo property. I'm
still not sure it is the best way of accessing this information. The main
problem with docinfo is that it currently is read-only. If we start using it
for adding processing instructions (i.e. for modifying trees), it would be
hard to explain why you can't change or add a DOCTYPE declaration the same way
(e.g. by throwing in a DTD object). So, starting work here implies a complete
rewrite of the DocInfo class - and I would prefer having a good idea about the
way it should look afterwards before wasting my time.

As usual, any patches are welcome and I'm very much open for suggestions here.
I just won't be the one fighting this through as I'm not too interested in
getting this in. (it's not something that can't currently be done, just
something that could need a good API to make it's usage a bit more efficient
and a lot more obvious).

Regards,
Stefan