- From: Steve Muench <Steve.Muench@oracle.com>
- Date: Tue, 27 Feb 2001 22:12:24 -0800
- 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 UTC