- From: James Clark <jjc@jclark.com>
- Date: Thu, 01 Jul 1999 19:32:21 +0700
- 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. James
Received on Thursday, 1 July 1999 08:46:28 UTC