[lxml-dev] lxml - addition of argument to control namespace declaration serializtion

[Stefan Behnel]

Hi,

these things are best discussed on the list.

Grimes, David wrote:
> In 1.3.5-1.3.6 timeframe, there was a patch introduced to
> _writeNodeToBuffer() from serialization.pxi which forced namespace
> declarations from parent nodes to be serialized onto the sub-tree root
> node.  In general, and with respect to XML standards, this make a great
> deal of sense (so you don't have prefixed elements/attributes without the
> corresponding namespace declaration).
>
> But, the application I've been building essentially takes an XML document
> and makes template-string blocks of text out of various sub-trees, to be
> later combined back into a full document using __getitem__ substitution in
> the form of "%(token)s" string formatting.
>
> The nsdecl patch of 1.3.5/6 causes interesting behaviour when the sub-tree
> being rendered is done in, for example, a loop - one "formatting
> operation" per iteration.  Also interesting is when many such sub-trees
> are combined to form a document which (in my case) we know will have the
> declarations on the ultimate root node.

What you mean is that we actually make a copy of a non-root node and then
copy over the namespace declarations of the ancestors. You say
"interesting behaviour". Does that refer to the performance overhead or is
there a 'real' problem you see?

Looking at the code now, I see some potential optimisations, so if it's
just the performance, here's a (trunk) patch that should give a bit of
relief.


> So ... I've got a patch I'm using in my local build which adds a keyword
> argument "nsdecl=True" to tostring(), tounicode() and tofilelike() - these
> are all the places which make use of the _writeNodeToBuffer() machinery.
> I can spin the patch against any 2.0.x or 2.1.x source tree.
>
> The argument defaults to True, to maintain backward compatibility, but can
> be provided as False to get <= 1.3.4 behaviour.
>
> Would you consider accepting this patch?

At first glance: no. I do not think there is general interest for a
serialisation that is not ns well-formed. You seem to have a rather
special use case here.

I'm not even sure you have to do what you describe based on serialised XML
fragments. You might be able to do something like that with subtrees. But
that's very close to guessing.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy-node-namespaces.patch
Type: application/octet-stream
Size: 786 bytes
Desc: not available
Url : http://codespeak.net/pipermail/lxml-dev/attachments/20080505/711237cc/attachment.obj