W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 1999

Re: XSLT 4/99 Spec

From: James Clark <jjc@jclark.com>
Date: Thu, 01 Jul 1999 19:32:21 +0700
Message-ID: <377B5FD5.98B0E992@jclark.com>
To: Jess M Holle <jessh@ptc.com>
CC: xsl-editors@w3.org
Jess M Holle wrote:
> I have been working with XSLT to produce HTML UI's from purely non-UI
> XML data representing various states.
> This spurs a couple of comments:
>   1) A few more string routines would be -really- helpful.
>      For instance, I would like to have a Java MessageFormat-like
>      XSL translation template.  The problem is that there is no
>      string replace functionality.  Moreover, substring-before() should
>      really return the entire first argument if the second argument is
>      not found in it -- this would allow a much cleaner implementation
>      of first-instance replace.
>      As it is I have a nasty bit of hard-wired XSL code that allows
>      up to 3 args to be replaced (i.e. '{0} is a {1} of {2}').

The XSL WG doesn't plan to add any new features before 1.0.

>   2) I parse the "Accept-Language" header in a Java servlet and send
>      it into the XSL as an input parameter.  This is all well and
>      good, but it is minimally useful because xsl:import and
>      xsl:include do not allow expressions!  If they did I could
>      write
>        <xsl:include href='concat("translationBundle_",$locale,".xsl")'/>
> Item (1) is obnoxious.
> Item (2) is a severe limitation.  I now have to have each XSL file
> translated (granted I can use xsl:variable to separate out the
> translation strings), rather than having separately translated resource
> bundles included from my main XSL files as I'd naively planned [I had
> assumed that xsl:include allowed XSL expressions].

I would suggest treating the translation bundle as another source
document rather than as an stylesheet.

Received on Thursday, 1 July 1999 08:46:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:16 UTC