xsl-list
[Top] [All Lists]

RE: Using or ignoring Types in XSLT 2.0 / XPath 2.0

2003-05-14 11:19:03
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(_at_)w3(_dot_)org(_dot_)

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(_at_)lists(_dot_)mulberrytech(_dot_)com 
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of 
me(_at_)robrohan(_dot_)com
Sent: 14 May 2003 18:12
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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