Subject: Re: [xsl] RE: For expressions and / operator in XPath 2.0 From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> Date: Thu, 3 Jan 2002 11:52:10 +0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] RE: For expressions and / ope, Michael Kay | Thread | RE: [xsl] RE: For expressions and /, Michael Kay |
[xsl] Urgent please folks, need hel, Manos Batsis | Date | Re: [xsl] The evaluate function, Trevor Nash |
Month |