- 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