Subject: Re: [xsl] Re: namespace values From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Tue, 13 Mar 2001 17:45:03 +0000 |
Hi Dimitre, > I admire your work and will certainly be glad to use a library of > ***standard*** XSLT templates, implementing the various functions > you proposed as part of XSLT. I also will be glad to contribute to > such an effort. OK, and yes I'm in favour of a repository for utility XSLT templates. They could even use the same set of namespaces without clashes, I think. But obviously XSLT templates allow you to do very different things than XPath functions. We won't be able to replicate some of them because they deal with things outside the scope of XSLT - an equivalent to exsl:node-set() for example. I guess we could fudge the ones that use node sets. For example, with set:intersection we could have: <xsl:template name="set:intersection"> <xsl:param name="node-set1" select="/.." /> <xsl:param name="node-set2" select="/.." /> <xsl:variable name="nnode-set2" select="count($node-set2)" /> <xsl:apply-templates select="$node-set1[count(.|$node-set2) = $nnode-set2]" mode="set:intersection" /> </xsl:template> People would have to call it with: <xsl:call-template name="set:intersection"> <xsl:with-param name="node-set1" select="$my-nodes1" /> <xsl:with-param name="node-set2" select="$my-nodes2" /> </xsl:call-template> and then write a template in set:intersection mode that did whatever they want done to the nodes in the intersection. But personally I'd find doing that a lot more work than doing: <xsl:apply-templates select="$my-nodes1[count(.|$my-nodes2) = count($my-nodes2)]" /> which at least I can use to apply templates in the order that I want and in the mode that I want. In my view, it would be even better if I could use: <xsl:apply-templates select="set:intersection($my-nodes1, $my-nodes2)" /> and didn't have to worry about getting that obscure XPath right. > However, I would not use any ***library of extensions***, regardless > of whoever created them. > > The former is absolutely needed. The latter I cannot risk to accept. > > I would probably accept more easily any vendour's extensions, > because they are undisguised extensions and I am clearly aware of > the cost I pay by using them. > > To summarise -- I am for the functionality, but strongly against > changing the language. [I'm a bit concerned that we're talking a little at cross purposes here - I'm talking about EXSLT in general rather than EXSLT - Functions (i.e. user-defined functions written in EXSLT).] EXSLT does not change XSLT in any way. The full name for EXSLT is "Extensions to XSLT" - it is all about extending XSLT, using the mechanisms that XSLT has provided for extending it. I'm afraid I really can't see how saxon:node-set() is an 'undisguised extension' whereas exsl:node-set() is (presumably) a disguised one? They are both functions with the same name and functionality in a namespace other than XSLT. Ahhh... I think that you think that there's an implicit claim that using EXSLT will make your stylesheets portable, whereas in fact this is not true - the stylesheet will only be portable if you port it to other implementations that support EXSLT. Is that it? I can add something like: "Using EXSLT will only make your stylesheet portable amongst the implementations that support EXSLT. Note that there is no requirement for XSLT processors that are compliant to XSLT to support the extensions described within EXSLT." Would that make it more acceptable? Are there other implicit claims that you feel that the EXSLT documents make about EXSLT? I think that adding either exsl:module-available() as Uche suggested or system properties in the EXSLT namespace for testing with system-property() will go a long way to helping authors test whether a particular implementation supports EXSLT. But the point is to move away from a situation where you have to do: <xsl:choose> <xsl:when test="system-property('xsl:version') >= 1.1"> <xsl:apply-templates select="$rtf" /> </xsl:when> <xsl:when test="function-available('saxon:node-set')"> <xsl:apply-templates select="saxon:node-set($rtf)" /> </xsl:when> <xsl:when test="function-available('msxml:node-set')"> <xsl:apply-templates select="msxml:node-set($rtf)" /> </xsl:when> <xsl:when test="function-available('lxslt:nodeset')"> <xsl:apply-templates select="lxslt:node-set($rtf)" /> </xsl:when> ... <xsl:otherwise> <xsl:message terminate="yes"> ERROR: Processor is unknown or doesn't support node-set extension function. </xsl:message> </xsl:otherwise> </xsl:choose> to: <xsl:choose> <xsl:when test="system-property('xsl:version') >= 1.1"> <xsl:apply-templates select="$rtf" /> </xsl:when> <xsl:when test="function-available('exsl:node-set')"> <xsl:apply-templates select="exsl:node-set($rtf)" /> </xsl:when> <xsl:otherwise> <xsl:message terminate="yes"> ERROR: Processor doesn't support exsl:node-set(). </xsl:message> </xsl:otherwise> </xsl:choose> Yes, we can't get there overnight. Yes, in the meantime you might want to add extra conditions to test for the implementations in implementation-specific namespaces. Yes, ideally some really common functions would be in the XSLT namespace and built in to every processor (and in this case will be in XSLT 1.1). But if we don't lay the foundations now, I'm worried that the situation is just going to get worse (especially with xsl:script being introduced) - we're going to see more and more implementations of the same functions in different namespaces, which is no good for anyone. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: namespace values, cutlass | Thread | Re: [xsl] Re: namespace values, Dimitre Novatchev |
RE: [xsl] copying source tree with , Michael Kay | Date | Re: [xsl] flushing a variable in XS, cutlass |
Month |