This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RE: For expressions and / operator in XPath 2.0
- From: Jeni Tennison <jeni at jenitennison dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 3 Jan 2002 11:52:10 +0000
- Subject: Re: [xsl] RE: For expressions and / operator in XPath 2.0
- Organization: Jeni Tennison Consulting Ltd
- References: <005601c19439$0be617c0$465169d5@pcukmka>
- Reply-to: xsl-list at lists dot mulberrytech dot com
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