W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2001

Re: XSLT Requirements v2.0

From: Steve Muench <Steve.Muench@oracle.com>
Date: Tue, 27 Feb 2001 22:12:24 -0800
Message-ID: <01a501c0a14d$6b18b930$72164498@us.oracle.com>
To: "Bevan Arps" <bevan.arps@actfs.co.nz>
Cc: "Xsl-Editors@W3.Org" <xsl-editors@w3.org>
Forwarding to xsl-editors for archiving.

XSLT 1.1 will provide the RTF-to-nodeset capability.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/

----- Original Message ----- 
From: "Bevan Arps" <bevan.arps@actfs.co.nz>
To: <Steve.Muench@oracle.com>
Sent: Tuesday, February 27, 2001 5:11 PM
Subject: XSLT Requirements v2.0


| 
| Steve,
| 
| Hope it is appropriate to email you direct - you're listed as one of the
| editors of the W3C working draft of the XSLT 2.0 spec. If not, I'd
| appreciate it if you could advise me to whom this email should be
| forwarded.
| 
| I've two suggestions that I hope you'll forward for consideration -
| these are issues that have come up in my own (limited, as yet) use of
| XSLT.
| 
| 
| 
| The first is the ability to convert a tree fragment to a node-set.
| 
| For example, I can currently write the following:
| 
| <xsl:variable name="tree.bits">
|   <xsl:call-template name="generate.tree"/>
| </xsl:variable>
| 
| The generate.tree template generates a structured tree of information,
| extracted (say) from the source document.
| 
| Problem is, the only thing I can currently do with this variable is
| output it. It would be extremely useful to be able to carry out further
| processing on this tree-fragment after generation.
| 
| My use case for this is in a formatter for XMI based specifications -
| currently I have two XSLT stylesheets, one to extract the documentation
| from the XMI file (generating documentation with part / chapter /
| section / subsection / paragraph nodes) and another to convert this into
| a set of XHTML pages. The reason the process is split into two is that I
| currently cannot generate the docs and then format them in the one
| stylesheet.
| 
| Ideally, I should be able to simply say
| 
| <xsl:apply-templates select="$tree.bits"/> 
| 
| and have the transformation from tree-fragment to node-set handled
| automatically. 
| 
| 
| 
| My second suggestion is to be able to give a value for the name
| attribute of xsl:call-template using an expression.
| 
| Currently this can't be done, and I have found this limits the use of
| standard templates, eg when generating XHTML documentation.
| 
| For example, consider a template to generate a customisable Heading in
| the output document:
| 
| <xsl:template name="generate.section">
|   <xsl:param name="caption"/>
|   <xsl:param name="style" default="chapter"/>
|   ...
| </xsl:template>
| 
| In the midst of this template, there is a need to invoke any of a series
| of other templates with xsl:call-template in order to do other
| processing as required with the section.
| 
| Currently, I have written this using a clumsy xsl:choose sequence like
| this:
| 
| <xsl:choose>
|   <xsl:when test="$style='part'">
|     <xsl:call-template name="generate.part"/>
|   </xsl:when>
|   <xsl:when test="$style='chapter'">
|     <xsl:call-template name="generate.chapter"/>
|   </xsl:when>
|   <xsl:when test="$style='section'">
|     <xsl:call-template name="generate.section"/>
|   </xsl:when>
|   <xsl:when test="$style='subsection'">
|     <xsl:call-template name="generate.subsection"/>
|   </xsl:when>
| </xsl:choose>
| 
| One disadvantage of this is how verbose it is.
| 
| A more significant one is that this template can only be used when one
| of those four types of processing is neccessary - ie the template is
| strongly coupled to its original use.
| 
| If I could write something like this instead:
| 
|   <xsl:call-template name="{concat('generate.', $style)}"/>
| 
| the template instantly becomes more generic (it doesn't explicitly know
| about the possible types of nested processing) and more reusable.
| 
| 
| Thanks for your time,
| Bevan.
| 
| -- 
| _______________________________________________________________________
| Bevan Arps, Senior OO Analyst             email: bevan.arps@actfs.co.nz
| ACT Financial Systems     "Programming is an Art Form that Fights Back"
| ***********************************************************************
| This  communication  is confidential  to ACT  Financial  Systems  (Asia
| Pacific)  and is intended for  use only by the  addressee.   The  views
| and opinions  expressed in  this email  are the senders  own and do not
| represent  the  views  and  opinions of  ACT  Financial  Systems  (Asia
| Pacific).
| ***********************************************************************
| 
Received on Wednesday, 28 February 2001 01:13:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT