[Xpath-ng] xpath-ng requirements

[Robin Berjon]

Hi Bryan,

bryan wrote:
> 1. Must Support the XML "Family" of Standards 
> 
> Fine, I define this family as XML 1.0, XML Namespaces, and the Infoset.
> Is there anyone else in this family, note that I left first cousins and
> the like out of my calculation, in your opinions?

I'd add that first-cousins ought to be "easy to support provided extensions to 
the language". In this case I'm thinking mostly about the idea of using 
annotations to access, say, schema information (yeah, I actually have a use case 
for this ;). I wouldn't however add that to the basic support.

>   1.4 Must Extend Set of Aggregation Functions 
> Yes. Min() and Max() are mentioned. Definitely, I would like to see
> better possibilities for calculation in XPATH-NG. A log function would
> be nice, and a round() just off the top of my head. Basically I want to
> be able to do calculation, generation of SVG easily in XSLT. With the
> understanding of course that different folks mean different things by
> easily. 

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.

That being said, once we have the basics I'd be delighted to contribute to an 
SVG module that will provide powerful functions to manipulate path data, 
bounding boxen, typical-to-SVG coordinate manipulations, etc.

> 1.5 Should Maintain Backwards Compatibility with XPath 1.0 
> 
> David Rosenborg said something like he wanted backwards compatibility to
> be at 99.4 %, which I take to mean that it should be possible for me to
> switch approximately 99 out of a hundred stylesheets to an application
> using XPATH-NG and suffer no ill-effects. 

I think we can first brainstorm and spec what we want, and then try to fix the 
proposed syntax to be more compatible. One compatibility option that I see as 
more important is grammar-compatibility, ie that a parser written for either 
version (ideally, but if not at least a NG parser) ought to be able to parse the 
tokens of the other version even if they don't make sense. It should be possible 
for it to skip parts that it doesn't understand and keep on parsing, the way CSS 
tried to do it.

That's the main reason why I was suggestin the function syntax to David in 
another thread.

> 2.1 Must Loosen Restrictions on Location Steps 
> 
> talks about allowing unions in location paths, I am for this part.

But allowing unions is not enough. Anything that returns a nodeset (or whatever 
we call it now -- perhaps a flat list of elements) ought to be allowed as a 
location step and should be filterable.

> 2.2 Must Provide a Conditional Expression 

Those could be in a module as well, with other control structures.

> 2.4 Should Support Additional String Functions 

I really want them, but I'd put them in a module as well.

> 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()).

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

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