[xsl] Re: Re: The Perils of Sudden Type-Safety in XPath 2.0

Subject: [xsl] Re: Re: The Perils of Sudden Type-Safety in XPath 2.0
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Wed, 26 Feb 2003 00:30:31 +0100
"Jim Melton" <jim.melton@xxxxxxx> wrote in message

>Américo Albuquerque wrote:
>>>I have the feeling that a group of people has the goal of making XSLT a
>>>ridiculous language.

> Absolutely!  About 12 or 15 of the best minds in the XML world have
> several years of their lives to creating a joke.  Nobody is expected to
> take all that work seriously.  The entire goal was to be so ridiculous
> we'd all laugh about it for years to come.
> Get real.
> The goal of the "group of people" has always been, and still is, to
> a new language that works well in the brave new world of XML Schema-typed
> documents.  If your documents are either purely DTD-based or have no
> metadata associated with them at all, then the features of XSLT 2.0 that
> correspond to the XSLT 1.0 specification are all you need use.  If you
> to deal with Schema-typed documents, then you have more power available.
> But please don't insult a group of people who are working their tails off
> to try to build a better future.  You might disagree with the goal, or
> the result.  But don't be so petty, please.

There are two things to be noted:

1. The above was said not by Américo, but by me.

2. What I find ridiculous is not the "new world of XML Schema-typed
documents ", but a functional language that will allow the following:

<xsl:variable name="x" select="0"/>
<xsl:for-each ...
  <xsl:variable name="x" select="$x + 1"/>


<xsl:variable name="x" select="0"/>

<xsl:variable name="x" select="3"/>

  <xsl:variable name="x" select="$x + 2"/>

If the only reason for this was "the ability to generate XSLT/XQuery code
automatically, and to allow cut-and paste of
code fragments" it would be much cleaner to provide for unique name
generation via a standard function and to achieve code re-use by well
established programming practices (e.g. abstraction and encapsulation) and
structure the code into reusable units (e.g. xsl:function).

As for who is offending whom, I think that the XSLT community should feel
offended by this excerpt of the WD:


It is also not an error if a binding established by a local xsl:variable or
xsl:param element shadows another binding established by another local
xsl:variable or xsl:param. However, such shadowing is discouraged and
implementations may output a warning when it occurs.

Thus, the following is not an error, but is discouraged, because the effect
is probably not what was intended. The template outputs <x value="1"/>,
because the declaration of the inner variable named $x has no effect on the
value of the outer variable named $x.

<xsl:template name="foo">
  <xsl:variable name="x" select="1"/>
  <xsl:for-each select="1 to 5">
    <xsl:variable name="x" select="$x+1"/>
  <x value="{$x}"/>

Or, are you proud to have this statement in the WD:

"Thus, the following is not an error, but is discouraged, because the effect
is probably not what was intended. " ?

Why are you creating *bad* features by design and even you, the authors
admit they are bad by saying in the spec that this "is discouraged"?

Please, understand me well. The new language may be brilliant and the
authors may be proud -- I don't have anything against this. The only thing I
care about is that this language will be called XSLT...

Maybe this can be a really good language -- it should be easy to achieve
this -- just remove the bad features, at least the ones that you, the
authors, openly mark as "to be discouraged" in the WD specification.

Dimitre Novatchev.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread