Mark Nottingham wrote:
> On 19/12/2007, at 12:12 PM, Brian Smith wrote:
> > Why not XPath or XQuery or SPARQL (with an Atom/RDF
> > mapping), or CSS selectors or some subset of one of those?
>
> In a nutshell, there are two reasons;
>
> 1) Those query languages are optimised for data models that
> aren't feeds; respectively, XML Infosets, Infosets again, RDF
> graphs and CSS cascades. While it's possible to contort them
> to fit feeds, they don't really lend themselves to it. XQuery
> and SPARQL also present a fairly high barrier to adoption (if
> you're not a big XML vendor or a SW-head, respectively ;)
> Contorting them so that they're easy to fit into a URL isn't
> too attractive, either.
>
> 2) When you expose a query interface, you're allowing people
> to consume compute power on your servers. An arbitrary query
> language allows arbitrary queries, which is unacceptable when
> you're working across administrative domains. FIQL gives you
> tools to constrain how queries are shaped.
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.
> Certainly there are use cases for using XQuery, etc.
> against feeds, but it's also become apparent that there's a
> place for something simple, reasonably flexible, and Web-friendly.
I agree. But, I'd rather borrow small parts from a well-specified,
widely-deployed, well-understood language than deal with a brand new
one.
> > 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.
> I'm open to other suggestions, but this seemed to be the
> simplest way to go about it. Note that the 'name' attribute
> on the fq:index element gives you a way to specify a stable
> name for a selector that's independent of the QName; if
> you're concerned about these issues, you can use that.
The language should not require implementations to match elements and
attributes using the prefixes used in the actual documents. XPath
expressions have a mapping of "statically known namespaces" [1] and the
default element namespace [2]. The fq:index could be the means of
setting up this mapping. Additionally, some extra syntax could be added
to support binding prefixes that are not bound in the fq:index.
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.
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.
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.
Regards,
Brian
