RE: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0

Subject: RE: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Wed, 14 May 2003 19:19:03 +0100
Your message won't fall on deaf ears - it will fall on no ears at all,
unless you post it as a comment to public-qt-comments@xxxxxxx

Specific suggestions for new names for selected functions are more
likely to achieve something than a generalized comment that the names
are too long.

There will almost certainly be some people on the working group who
agree with you. Whether there are enough people to make it happen is
always hard to predict. Small changes always stand a better chance than
big changes.

Michael Kay

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> me@xxxxxxxxxxxx
> Sent: 14 May 2003 18:12
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
> 
> 
> > > The message that XSLT users don't want all this
> > typing
> > > appears to fall
> > > on deaf ears since its apparently vital to the
> xquery
> > input
> > > to the working group.
> > 
> > The message that the above statement is rubbish seems
> > to fall on even
> > deafer ears.
> 
> Oh my - I missed most of this thread, but this sounds
> like an on going, heated, battle. Forgive me if I am
> out of place or way off but this is a gripe of mine
> too. I would like to throw in my £0.02. I am fairly
> positive this has been said before, but I would like to 
> reiterate it from an in-the-field-programmer who has no clout.
> 
> Xpaths functions are ridiculously long. I have a hard
> time getting programmers to adopt xslt because the
> functions are not even close to any other language. 
> 
> Often times one can find similarities between
> languages, which helps to shorten the learning curve.
> For example, (my favorite)
> 
> (most) SQL:
> SELECT TRIM(mything)
> 
> JAVA:
> String booga = mystring.trim()
> 
> DELPHI:
> function Trim(const S: string): string;
> 
> VB:
> Trim() 
> 
> XPath / XSLT:
> normalize-space() ?
> 
> What? I realize that [lf][tab] are normally not
> included in trim functions, but I think it's easier to
> say, "in xslt trim() removes line feeds" then "sorry,
> you have to learn a whole new vocabulary"
> 
> Some of the functions are just insane. A good example
> is "subtract-dateTimes-yielding-yearMonthDuration" -
> yes I can tell what it does by looking at it; however,
> if you think most 'normal' programmers are going to
> memorize it and type it day in and day out, I think you
> will be disappointed (using the US programmers I have
> met over the years as my basis). 
> 
> I guarantee I could talk many (US) programmers *out* of
> using xslt simply by showing them functions that are
> this verbose.
> 
> I mean, there is a reason it's
> <command>
> mov ax, bx
> </command>
> and not
> <command>
> would-you-please-move-the-contents-of-register AX 
> to-the-register BX thank-you </command>
> 
> I understand the reasoning behind the verbosity, but I
> think it goes a bit too far.  
> 
> I look forward to 2.0 where I can (hopefully) replace
> these functions with whatever I want. Meaning
> 
> <xsl:function name="trim" ...
>   ... do normalize-space and return results
> </xsl:function
> 
> So, as has been said before, I think the function's
> names are too long.
> 
> - ok so perhaps it was only £0.01
> 
> - Rob Rohan
> 
>     _/  _/_/    _/_/_/
>    _/_/   _/ _/     _/
>   _/               _/
>  _/             _/
> _/          _/_/_/_/
> http://treebeard.sourceforge.net
> http://ashpool.sourceforge.net
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> 


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


Current Thread