[Xpath-ng] xpath-ng requirements

[Robin Berjon]

bryan wrote:
> Well modules seems to be the meeting point for a lot of people so I
> suppose it's okay with me, note though that my whole point was starting
> from the Xpath 2.0 requirements doc http://www.w3.org/TR/xpath20req .

Yes, I'm aware of that, and I freely admit to being obsessed with modularization 
in the context of XPath. It's so useful that people naturally want more from it, 
but it can't become the dumping ground for everything. And that even though the 
schema stuff in XPath 2.0 happens to be useful to me :)

> Since I am of the opinion that the best strategy(not necessarily
> programming strategy) is to produce something that can function as a
> communique to W3C on the lines of: "this is what the xpath using
> community wants, much of it follows through on what you proposed so you
> guys are really great, but just without the Xml schema/ Xquery
> integration stuff, which it should be noted that by leaving all that out
> we managed to write a 75 page spec, and perhaps you should take this
> under consideration and stop the other nonsense"  or something as polite
> as that(Perhaps that is a little much actually). 

It would be nice were that to happen, but I given how strongly XPath 2.0 is 
linked to other important and potentially complex specs, I doubt it'll have much 
effect.

> I was of the opinion that replace() should be an XSLT-NG function.
> Although in another way that's somewhat silly, as my main reason is not
> to have something that can 'change' the string in my selection language,
> but there's already that in the way of translate(), and round().

This raises an issue: should it do replace in place, or return the replaced 
value? When doing [@foo = replace($var, "(.)+", "\1", "g")] you might not want 
$var to be modified, just to test its value with a replacement expression. If it 
doesn't operate in place then there is no real changing of the string.

> This would I think be useful for SVG when you often have paths that
> contain numbers with three or four significant digits to the right.
> Round($value,0) with $value equaling -2.754 would round to -3 as it does
> now, round($value,3) would round to -2.750

That would be especially useful in the context of converting SVG Full to SVG 
Basic, where floats are limited to four decimal places.

>>Hmm, don't take it the wrong way that looks suspiciously like VBScript
>>to me :) 
 >
> SIR!! How dare you insinuate that my fingers have ever typed anything
> but the pure functional code!! :)

I retract my comment, I guess it must have been Outlook2000+Word insisting on 
making it look that way ;)

> These are also from xquery-operators as linked to above, or at least
> they were, haven't kept track recently but I see that string-pad is
> still there http://www.w3.org/TR/xquery-operators/#func-string-pad

Hmm, I promptly forgot almost everything I learnt about XQuery due to my 
XQuery-related project being deferred. I still think they are rather useless 
duplicates, but I don't have strong feelings about functions (so long as they 
stay in module and I can implement my own ;).


>>How about having the equivalent to Perl's "x" operator which repeats a
>>string n 
>>times in "string x n"? repeat-string("string", 5) or something similar?
> 
> One of the ways that I figured we could humble us before the W3C when at
> last Xpath-NG was presented might be in having the same
> long-winded-names-that-spell-out-everything-the-function($does) but if
> others don't like this way of naming I don't care, 

While that is a good political move in theory, as I said I don't think there's 
any hope of changing XPath 2.0 to XPath NG, or I'll be very (though pleasantly) 
surprised. I think we should think about what we like and take 
community-fixes-w3c politics into consideration.

-- 
Robin Berjon <robin.berjon at expway.fr>
Research Engineer, Expway
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488