RE: [libxml++] Preserving whitespace

[<and...@am...>]

> > PS I've also tried applying xml:space="preserve",
> > without luck.
> 
> What is that?

See  http://www.w3.org/TR/REC-xml#sec-white-space
in XML 1.0 spec, Second Edition.

Basically, the attribute xml:space can be attached to any element.
Value xml:space='preserve' means that whitespace must be preserved
for that element, by whatever application you are using.
Value xml:space='default' means that the application should
do whatever whitespace handling it wants to do.

Thus, an indenter might legitimately look at
<foo><bar xml:space='preserve'> 
  a
    b
c</bar><baz><biff/>blick</baz></foo>

and produce
<foo>
    <bar xml:space='preserve'> 
  a
    b
c</bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>

The attribute xml:space is pretty verbose;
typically, you might want to apply it via a style
sheet in some preliminary transformation.
Hmmm... not sure if DTDs can specify it as a 
default attribute.  Doesn't matter to me,
since my problem domain is DTD averse.



Note:  I find: the semi-indented

<foo>
    <bar xml:space='preserve'> 
  a
    b
c</bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>

pretty unreadable (and I'm used to it
from LISPing for many years).   I prefer something like:

<foo>
    <bar>
        <br/> 
        <raw>  a</raw><br/>
        <raw>    b</raw><br/>
        <raw>c</raw>
    </bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>

or 

<foo>
    <bar>
        <br/> 
        <bol/>  a<br/>
        <bol/>    b<br/>
        <bol/>c
    </bar>
    <baz>
        <biff/>
        blick
    </baz>
</foo>


(the latter form has fewer problems with 
strict nesting.)

Unfortunately, there is no standard,
although adding xml:space='preserve' 
to <raw>...</raw> comes close.




==========


> > E.g.  I might want to be processing multiple documents
> > at the same time, one of which preserves whitespace and one
> > which does not.
> 
> I don't believe libxml++ should ever destroy your significant 
> white space, and I don't think it should have even an optional 
> feature to do that.

Good. I will reupdate and see if it all works.


> In general there should be no global behaviour with libxml++.

That's what I want to hear.

There will probably be bugs, because libxml has global behaviour.
But  think the libxml people will be interested in evolving
towards non-global, context object, behaviour, too, albeit
in C syntax.