RE: [libxml++] Preserving whitespace
- From: andy glew amd com
- To: libxmlplusplus-general lists sourceforge net
- Subject: RE: [libxml++] Preserving whitespace
- Date: Mon, 12 May 2003 11:44:05 -0700
> > 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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]