Re: [xsl] RE: For expressions and / operator in XPath 2.0

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Mike,

> Yep. We've certainly now got a rather idiosyncratic mix of syntactic
> styles: essentially the old path syntax, based on the same kind of
> thinking as regular expressions (terse, readily understood by
> experts, total gibberish to anyone else), mixed in with an SQL-style
> keyword syntax. I suspect this was inevitable, even without the XML
> Query input: we were running out of ASCII characters.

I do have a quite visceral reaction against all the keywords; I think
it's because I imagine the expressions being used within attributes in
XSLT, and how confusing that mix is going to be. If XPath were a
stand-alone language (like XQuery is), I think I'd welcome the
verbosity with open arms.

And introducing keywords obviously causes problems - having to put a
colon in front of element names that could be keywords is really ugly,
in my opinion. I also think that it will encourage newcomers to
(wrongly) think that you need to have a : in front of all unprefixed
QNames, or that :for is a valid QName.

Personally, I'd prefer to see XPath kept concise - if you run out of
ASCII, drop some functionality. But maybe I'm just having a negative
reaction to change, or perhaps I like explaining gibberish.

> I did at one stage suggest using backslash for a sequence mapping
> operator
>
>    //rate \ (@value * @quantity)
>
> and I've never had so many rotten tomatoes thrown at me in my life!
> (It seems 90% of Microsoft users, which means 80% of the world
> population, are incapable of distinguishing "/" from "\").

:) Yes, we are ;)

> Another proposal was a simplified FOR expression without range
> variables, e.g.
>
>    for //rate return (@value * @quantity)
>
> but this gets into reserved-word parsing problems.

But don't you have reserved-word parsing problems all over the place
anyway? I'd prefer an operator (e.g. "->"), but getting rid of the
range variables would be a step in the right direction, in my opinion.

One advantage of an operator for the for expression is that it would
allow you to 'pipeline' sequences through a series of operations more
easily (which is one of the advantages of the location path syntax,
especially now that function calls are allowed in general steps).

Say you had a sequence of numbers (conceptually coordinate pairs). You
could do a 'scale' operation by multiplying the pairs by 2:

  $coordinates -> (. * 2)

and then do a 'move' operation by adding 50 to the odd numbers:

  $coordinates -> (. * 2) -> (if (position() mod 2) then . + 50 else .)

I think that this is easier to manage than:

  for (for $coordinates return (. * 2))
    return (if (position() mod 2) then . + 50 else .)

[Of course I'd also prefer the conditional expression to have a
non-keyword syntax, so you actually had:

  $coordinates -> (. * 2) -> ((position() mod 2) ? . + 50 : .)

which perhaps illustrates the gibberish factor :)]

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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