[xsl] paras with nested block-level elements to XHTML mix of <p>s and flattened block-level elements

Subject: [xsl] paras with nested block-level elements to XHTML mix of <p>s and flattened block-level elements
From: Daniel Grossberg <danielgr@xxxxxxxx>
Date: Fri, 01 Aug 2008 13:38:56 -0500
My question concerns X/HTML as the transformation target, where "p" is the lowest level block-level element, which admits no other block-level element(s) as content, but the source is a model (like DocBook, TEI, etc.) which allows (and has) a variety of block level content in paragraphs.
This doesn't appear to be a new problem... but while I've tried, I just haven't been able to track down any definitive solutions.


>From XSLT Requirements, Version 2.0, W3C Working Draft 14 February 2001
http://www.w3.org/TR/xslt20req
Under 4, the Simplify Grouping subsection:
Item 9. Transform Inline <para> Elements to Block <para> Elements
Transform from a DTD that allows para elements to have nested block-level elements to a DTD that requires para elements to have only inline elements, e.g. transform:


<p>Do <em>not</em>:

<ul>

<li>talk,</li>

<li>eat, or</li>

<li>use your mobile telephone</li>

</ul>

while you are in the cinema.</p>


into:


<p>Do <em>not</em>:</p>

<ul>

<li>talk,</li>

<li>eat, or</li>

<li>use your mobile telephone</li>

</ul>

<p>while you are in the cinema.</p>

________________________________________

Questions for the XSL list: How does one solve this problem in XSLT 1.0? What is the optimal solution now, using XSLT 2.0?
To be comprehensive, the transform needs to account for not only the particular case above in the source... but also cases where text / mixed content might not follow after the close <ul> tag (, e.g:



<p>Do <em>not</em>:


<ul>

<li>talk,</li>

<li>eat, or</li>

<li>use your mobile telephone</li>

</ul>

</p>

and likewise, cases in the source where there's no text or mixed content preceding the <ul> tag... (e.g., <p><ul>... ... ...</ul> text.</p>).
My searches for existing solutions to this using XSLT 1.0 and 2.0 have not met success, tho it seems like a pretty common problem for any conversion from a number of DTD standards to X/HTML.


Any suggestions for a robust method to handle this kind of problem... and/or pointers to solutions that have already been developed for this would be most appreciated.
Thanks!


daniel

[PS. For testing, I use the Saxon XSLT processors for XSLT 1.0 and 2.0 as provided with the latest oXygen editor, v9.3]

Current Thread