[Xpath-ng] xpath-ng requirements
bryan
bry at itnisk.com
Thu Nov 28 03:38:45 MST 2002
I was thinking as a way of saying where this is going, perhaps we should
define requirements first by going through the XPath 2.0 requirements
from W3c and see what should be dropped, this is of course just a
suggestion, others may see it as more beneficial to write up a list of
requirements without any reference to the XPath 2.0 situation. Some of
this mail will go into direct issues of syntax, this because I find that
if I talk too long about abstract things at too high a level of
abstraction I tend to get confused and would like to see some syntax,
the discussion here has been very abstract it seems to me, so I would
like to see some syntax.
Here is the list of requirements:
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?
1.1 Must Express Data model in Terms of the Infoset
I guess I find that acceptable.
1.2 Must Provide Common Core Syntax and Semantics for XSLT 2.0 and XML
Query 1.0
I believe that is dropped, :) there was some discussion of an XSLT-NG so
we would have something for XPATH-NG to be hosted by.
1.3 Must Support Explicit "For Any" or "For All" Comparison and Equality
Semantics
I am conflicted about this.
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.
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.
1.6 Should Provide Intersection and Difference Functions
I don't think anyone would be against this.
1.7 Should Support Unary Plus Operator
I don't know if I care for this, I think that it might be better if one
could define specialized types of numbers. Jeni talked about having the
possibility of scientific notation, maybe there could be some overarcing
way of handling all non-regulary numerical types.
2 Must Improve Ease of Use
Hmm, time was I would have indulged in sarcasm at this point.
2.1 Must Loosen Restrictions on Location Steps
talks about allowing unions in location paths, I am for this part. Not
so sure about the xpointer and node-set functions examples.
shows syntax suggestion of /foo/(xxx|yyy)/li/(p|eg)
in opposition to the more cumbersome
/foo/xxx/li/p |
/foo/xxx/li/eg |
/foo/yyy/li/p |
/foo/yyy/li/eg
seems reasonable as the second should still function.
2.2 Must Provide a Conditional Expression
There seems to be people who are for this, and those who are against it
as the languages which embed xpath-ng will have their own conditional
expressions. I am against. When I first read of it I thought it was a
cool idea, later after thinking about it I changed my mind, questions
about debugging coming uppermost. I've only ever felt the need for a
conditional expression in my XPath once, this was because a co-worker
asked me for an XPath for an app he was working on, I didn't want to
discuss the app logic so I just wanted to solve the problem with one
xpath, I spent some time on it and nearly gave up when I realized that
what I had been thinking was a very complicated problem that actually
required conditional expressivity was in fact a relatively simple not().
The point being that many difficulties are ones of point of view.
Setting Requirements by anecdote may not be the scientific manner, but
voting on requirements seems to me to be well served by personal
experience.
2.4 Should Support Additional String Functions
Yes. A propos that lets just say what string functions I think are
necessary for XPATH-NG.
Starts-with(string1,string2)
Ends-with(string1,string2)
Match(string1,regex)
Normalize-unicode(string,normalizationcCode)
I don't think that the codepoint functions should be part of Xpath-NG
mainly because, as enticing as they are, I don't think they will help
our case any unless there is an implementation with support for
codepoint across the main Western European languages, that's some work I
suppose.
People have asked for upper-case and lower-case and I certainly don't
mind having them, but it's one thing to ask for a function when one is
new to the language, it's another thing to work with xpath for a year
and to keep asking for a function, and bemoaning the lack of said
function. I think that's something to keep in mind.
A propos the XSLT-NG idea, if there were an XSLT-NG then I think these
functions should be supported in XSLT-NG, which is why I have left them
off the XPATH-NG list.
XSLT-NG additional string functions:
String-pad-beginning()
String-pad-ending()
String-pad() - maybe should be called string-pad-count()
Replace(string1,regex)
Okay that takes us to section 4 of the requirements.
4 Must Add Support for XML Schema Primitive Datatypes
Hahah - uhh, no. the only two parts I consider interesting in section 4
are the following:
4.2 Must Allow Scientific Notation for Numbers
see 1.7
4.4 Should Add List Data Type to the Type System of the Expression
Language
David Rosenborg has been discussing being able to select against lists,
am wondering David if your suggestions on this matter are in reference
to this section?
Okay , as section 5 is more schema stuff I'd like to stop this email
here and ask if anyone has any points.
More information about the Xpath-ng
mailing list