Re: [xsl] Re: namespace values

[Jeni Tennison <mail at jenitennison dot com>]

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