[Xpath-ng] xpath-ng requirements
bryan
bry at itnisk.com
Fri Nov 29 09:14:46 MST 2002
Robin Berjon wrote:
>I think that everything that isn't completely "core" should go into
>external
>modules. "XPath NG Core" would ideally be very small. I'll be a lot
happier >when
>I can trivially embed an XPath resolver in a numeric radio. To avoid
having >to
>prefix every function, we could perhaps define some modules as being
part >of the
>Basic Profile and declare them prefixless.
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 .
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).
>> Starts-with(string1,string2)
>> Ends-with(string1,string2)
>> Match(string1,regex)
>> Normalize-unicode(string,normalizationcCode)
>I'd make those lowercase to be consistent with the rest of XPath. I'd
also >throw
>in replace(string, regex, replacement [, flags]) here and make match()
>similarly
>flaggable (there's no reason to have one but not the other). The
starts->with()
>and ends-with() functions could be either replaced with match(), or
with an
>index() function that could take a startPosition param (-1 being the
way to
>switch to ends-with()).
Yeah I'm emailing in Outlook 2000 currently and it defaults to Word as
its email editor, which I'm fine with(got all my patches running) but it
does tend to capitalize new lines, I didn't want to go back and
uncapitalize them, since these functions are some of those defined in
http://www.w3.org/TR/xquery-operators/
I figured I would choose the ones that seemed reasonably useful to me.
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().
A propos round() this is one of the math functions I would like to see
improved, with for example the ability to set digit positions to round
to. But I think I might already have mentioned this in another thread.
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
I don't know if other people often feel the need for such a function,
but it is one I feel every now and then, and it's not particularly the
kind of thing I want to solve by splitting the string and then rounding
individual numbers y'know? (Probably someone knows a good way to solve
this and will point it out to me now.) :)
> People have asked for upper-case and lower-case and I certainly don't
> mind having them,
I think they are vital to people that wish to handle I18N easily and
efficiently.
>> String-pad-beginning()
>> String-pad-ending()
>> String-pad() - maybe should be called string-pad-count()
>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!! :)
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
>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, I'm basically just
concerned that something I would like to work with comes out of all
this, although if my workload should somehow lighten I might find the
time to build a Rebol implementation - without the XSLT-NG though. :)
More information about the Xpath-ng
mailing list