[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: For expressions and / operator in XPath 2.0

Subject: Re: RE: For expressions and / operator in XPath 2.0
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Thu, 3 Jan 2002 11:52:10 +0000
xpath query and operator

> 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 :)]



Jeni Tennison

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.