Next in thread → Next in month →

Re: [docbook] xml:space or not

From
Bob Stayton <>
Date
2009-09-28T16:42:46+00:00
ID
000501ca405a$aead55b0$0a00a8c0@pazu
Thread
Re: [docbook] xml:space or not
Hi Gregor,
I'm not sure it is appropriate to add xml:space="preserve" to all mixed 
content elements. That attribute tells applications to preserve *all* white 
space.  Wouldn't that have the unintended consequence of preserving indents 
and line breaks within a para in its formatted output?  The default behavior 
in XSL-FO is to collapse multiple white space characters into a single 
space, giving paragraphs the nice formatted flow.  If a stylesheet 
encounters an element with xml:space="preserve", that should override the 
default behavior if the processor were behaving correctly, no?

Bob Stayton
Sagehill Enterprises



----- Original Message ----- 
From: "gregor FELLENZ" <>
To: <>
Sent: Wednesday, September 23, 2009 6:17 AM
Subject: [docbook] xml:space or not


> hi list,
>
> this is an more philosophical thought/question. i'm tested some docbook 
> documents and playing with some custom xslts.
>
> problem is indentation and strip-space.
>
> with my xslt i need to strip all white space between non mixed content 
> elements.
>
> problem with the following snippet:
> <para><emphasis>em1</emphasis> <emphasis>em2</emphasis></para>
>
> with <xsl:strip-space elements="*"/> this is transformed to: 
> <para><emphasis>em1</emphasis><emphasis>em2</emphasis></para>
>
> which is obviously not what i want. with:
> <para><emphasis>em1</emphasis> x <emphasis>em2</emphasis></para>
>
> everything works fine, whitespace is preserved.
>
> i know how to get around the limitation with:
> <xsl:preserve-space elements="para"/>
>
> in this case i have to add any mixed content element to the list, i.e. 
> reading the whole dtd checking/adding every element.
>
> wouldnt it be better to add an fixed attribute to any mixed content 
> element like:
> xml:space CDATA #FIXED "preserve"
>
> this would help not only with xslt transformation also with pretty print 
> functions (assumed the dtd is interpreted). and would make clear how to 
> handle the current element.
>
> i'm not assuming that this is added in near future, i would be more 
> interested if this idea was discussed. and/or if this method causes any 
> problems with custom dtds.
>
> hope this question is fitting into the list topic!
>
> all the best,
> gregor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 
>
>
>
Next in thread → Next in month →