On 19/12/2007, at 6:54 PM, Brian Smith wrote:
Developers are used to seeing subsets of XPath. Almost every XPath
implementation I have seen has been a subset of XPath; Sometimes the
explanation was avoidance of DoS (resource consumption) attacks; other
times, the explanation was "we didn't have the resources to implement
all of it." So, I think it is reasonable to attempt to use a subset of
Xpath as a query language.
Hmm, I'm not sure the latter is a great advertisement for basing it
upon XPath...
To my mind, XPath 2.0 (which you seem to be referring to) is too
complex to base something like this on; printing the XQuery-related
specs kills too many trees, and it takes a major investment to get up
to speed with it as a user, much less an implementer. While it works
if you're already invested in the XQuery world, my perception is that
this group is still fairly small, and "enterprise" focused.
I don't keep up to date with the XQuery world, but last I checked,
Perl, Python, PHP and Ruby all lacked implementations. What will they
do?
In comparison, FIQL has been prototyped in a small amount of part-time
effort by a single developer (yes, I'm trying to get that Open
Sourced, but don't know when/if that'll happen).
That is not acceptable. First, namespace handling in
feed-consuming software is bad enough as it is.
While true, I don't see how that's relevant.
It creates confusion. We spend a lot of time explaining to people that
they should always prefer to match elements by their namespace URI and
never by their prefix. This is making an unnecessary exception to that
rule.
Yes. I think the issue here is whether the convenience outweighs the
confusion. Perhaps we could make the binding between selectors and
QNames not on by default; instead, a feed would have to specifically
say that it's in effect (e.g., in a fq:interface attribute)...
I will throw out this suggestion for using a subset of XPath 2.0 as
the
constraint language.
Expr ::= AndExpr ( "or" AndExpr )*
AndExpr ::= CompExpr ( "and" CompExpr )*
CompExpr ::= Value ValueComp Value
| FunctionCall
| "(" Expr ")"
Comp ::= "eq" | "ne" | "lt" | "le" | "gt" | "ge"
Value ::= Literal
| Path
| "(" Value ")"
Path ::= QName
Literal ::= NumericLiteral (as defined in XPath)
| StringLiteral (as defined in XPath)
FunctionCall ::= "matches" "(" Qname "," RegEx ")"
| "matches" "(" Qname "," RegEx "," "'i'" ")"
| "not" "(" FunctionCall ")"
RegEx ::= "'" ".*"? CHAR* ".*"? "'"
Char ::= <any character except ".", "'", or """> | "\" <any
character>
I believe this language to be very similar to the language that you
specify in the draft, while simultaneously being a pure subset of
XPath.
As you can see below, it isn't beautiful. But, I don't think that it
is
so ugly that it requires a whole new language to replace it, either.
Now that's interesting! I've had the XQuery/XPath 2.0 discussion with
others before, and the resolution was that as long as it was possible
to map it to XPath for implementation purposes, that's good enough --
something that it looks like you've taken a step towards.
I'm not married to the current syntax, but I do want it to be URI-
friendly and easy for humans to understand. If the syntax meets those
goals and happens to be a subset of XPath, I'm fine, but I don't want
to define it as an explicit subset; doing so will force people to
learn XPath whether they want to or not, and IMO will lead to interop
problems as people start relying on XPath features, rather than what
the spec says.
Anyway, this is good; I'd be interested in hearing what other Atom
folks have to say about the alternative syntax, and whether it's good
enough to have an easy way to turn it into XPath if necessary.
The expression would always be considered to be a XPath predicate.
That
is, an expression X would be evaluated as:
atom:entry[X]
and the resulting node list would be wrapped in an atom:feed element.
The default element namespace binding is the Atom namespace. Analogous
considerations apply to RSS. The default function namespace is
http://www.w3.org/2005/xpath-functions.
FIQL:
title==foo*;(updated=lt=-P1D,title==*bar)
XPath:
(matches(title,'foo.*'))and((updated)lt('-
P1D')or(matches(title,'.*bar')
))
FIQL:
title==*new*,author==bob*
XPath:
(matches(title,'.*new.*'))or(matches(author,'bob.*'))
FIQL:
title==*great*;ex:rating=gt=4
XPath:
matches(title,'.*great.*', 'i')or(ex:rating)gt(4)
Further, lets extend the syntax the subset to include a little more
XPath:
Value ::= Literal
| Qname
| "(" Value ")"
| "xs:dateTime" "(" Value ")"
| "xs:duration" "(" Value ")"
| "xs:decimal" "(" Value ")"
Now, the client can explicitly request certain values to be treated
as a
specific type in variables, regardless of what the fq:index elements
do
or do not say.
I wonder if that's a good thing or not...
Further, we can expand the syntax of paths to allow us to select
nested
elements and/or attributes or anything else that XPath allows. For
example, atom:content/@type.
Again, hmm. The ability of fq:interface to constrain the shape of
queries is a good thing.
--
Mark Nottingham http://www.mnot.net/
