[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Findings: Merging XSL:FO & HTML Style Sheets

---

---

Greetings All,

	A couple of days ago I asked some questions on merging style sheets
for both XSL:FO and HTML, the reason being that a majority of the
processing is essentially identical for both forms of output. And it
creates a maintanance nightmare to have to try and keep in sync
separate files.

	Anyway the final result is 4 XSLT files, consisting of 3 wrappers (one
for each of HTML, XHTML, FO) and the core style sheet.

The wrappers are necessary as the <xsl:output> element's attributes can
not be substituted with parameters/variables and XSLT does not support
<xsl:choose> outside of <xsl:template>. The wrappers consist merely of
the standard header trailer for valid XSLT, an <xsl:output> element
setting up the necessary parameters for each generation mode and an
<xsl:include> of the core XSLT file.

ASIDE: From this experience I'm considering if it is worth while to
mail the w3c XSL-Editors Group with a proposal I'm loosing calling
"Further support for simple variable / parameter expansion in XSLT
attributes". I was wondering whether the lack of expansion of
attributes was something causing others on the list to jump thru
unnecessary hoops and if we should, as a list, have a discussion on
such issues.

Anyway the method which is working for me for the core XSLT file, is
the use of numerous key named templates to push down (defer) generation
of the actual output tags (ie the HTML and FO) and within these
templates and others, wrapping of all tag generation in <xsl:choose>
elements.

To give you an idea of the named templates I used, here are the names
of a few of the key ones which greatly simplified the task:
MakeLinkInternal, MakeLinkExternal, SectionBegin, SectionEnd,
MinorHeading, GenerateTableRow, GenerateTableRowLabel,
GenerateTableRowContents

Also for some simple cases the following proved useful (note that
OUTPUT_MODE is a global parameter):

    <xsl:variable name="enclosingTag">
      <xsl:choose>
        <xsl:when test="$OUTPUT_MODE = 'FO'">fo:block</xsl:when>
        <xsl:otherwise>p</xsl:otherwise>
      </xsl:choose>
    </xsl:variable>

    <xsl:element name="{$enclosingTag}">
	<!-- ... -->      
    </xsl:element>

Unfortunately the <xsl:element> use-attribute-sets only accepts a
"qnames" not "{qnames}" (Mulberry Tech XSLT Quick Ref Syntax) which is
really unfortunate as this simple change (which BTW is implemented in
xsltproc) would be very useful in this case (ie: merged style sheets)

Similarly the ability to define nested sets of elemnts and attributes
which could then be treated a single unit and called on would be
brilliant in the merged style sheet situation. In this situation as I
envisage it, parameters could be set on initialisation to determine
which tags set would be in use. I can dream - and the W3C can make all
your wishes come true ;-)

Imagine:

  <xsl:use-element-attr-set name="{$tableStructure}">
     <xsl:use-element-attr-set name="{$tableRowStructure}">
	<xsl:use-element-attr-set name="{$tableCellStructure}">
	  ...
	</xsl:use-element-attr-set>
	<xsl:use-element-attr-set name="{$tableCellStructure}">
	  ...
	</xsl:use-element-attr-set>
      </xsl:use-element-attr-set>
      ...
   </xsl:use-element-attr-set>

Or even better remove the need to define indirection variables such as
"tableStructure", "tableRowStructure", ... (to point the relevant names
for the current output mode) and allow slightly fancier name lookup
like:
    <xsl:use-element-attr-set name="{tableStructure-$OUTPUT_MODE}">

Anyway I hope this helps and gives a feeling for some of the features I
would see as useful in a future XSLT specification.

Regards,
Peter Bray
Sydney, Australia

http://movies.yahoo.com.au - Yahoo! Movies
- Vote for your nominees in our online Oscars pool.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---