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 news:4.3.2.7.2.20030225144922.052e2068@xxxxxxxxxxxxxxxxxxxxxxxxxx >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 devoted > 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 that > 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 produce > 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 want > 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 with > 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"/> or <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: <quote> 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"/> <xsl:for-each> <x value="{$x}"/> </xsl:template></quote> 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: The Perils of Sudden , S Woodside | Thread | [xsl] Question about grouping into , Ramesh Thummalapenta |
Re: [xsl] Re: The Perils of Sudden , S Woodside | Date | [xsl] entity declaration error, Mac Martine |
Month |