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

["Kurt Cagle - Olywa" <cagle@xxxxxxxxx>]

Rob,

If it's any consolation, I think that outside of the (somewhat spurious)
date specifications the function names are actually pretty reasonable.
Consider that normalize-space() does more than just trim - it converts all
interior white space in a string into single space characters. Those
functions that a developer will use 90% of the time are fairly terse, and
the 10% of the time you'd probably want to look them up anyway.

I still contend that type doesn't belong in XSLT, but if it is in there, it
should make processes more efficient, not less. If type needs to be there,
then all of XSD should be supported, such that an XSLT function can return
an object of complex type Foo.

-- Kurt

----- Original Message -----
From: <me@xxxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 14, 2003 10:11 AM
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