While the xpath examples are definitely more complicated, I think in this case I've got to agree with Brian. Using an existing, known query mechanism is better that inventing yet another one. Also, given that Atom is, in fact, XML, it makes a lot of sense to use a query language designed for use with the XML Infoset. It may not look as pretty and compact as Mark's new syntax but it works, it already exists, there is existing tool support, and it already covers many of the difficult issues like namespaces and extensions.
If we do use xpath, I would suggest that the default namespace *always* be mapped to the Atom namespace so users will never have to worry about the namespace prefix. In fact, all known *standardized* atom extensions should have prefixes defined in the spec. E.g. the query spec could say that the prefix thr: always maps to the threading extension and that xhtml: always maps to XHTML so that we don't have to worry as much about namespaces. For more complicated cases, XPath provides the means of specifying namespaces, even if it's not that pretty. We would, however, likely need to provide coverage of things like relative uri's. For instance, if I submit a query like "matches(link/@href,'http://example.org/foo')", it should be capable of matching against elements like <link href="/foo" xml:base="http://example.org/bar"; />. With base XPath, AFAIK, this is not currently possible. Also, if it is at all possible, it would be ideal if we could automatically map the atom date elements (updated, published and app:edited) to the xs:dateTime in XPath so we can simplify those operations a bit, e.g. updated eq fn:current-dateTime as opposed to xs:dateTime(updated) eq fn:current-dateTime Both should be possible but the former is definitely easier. Regarding fq:interface, I'm not convinced the fq:index bit is necessary; and I'd much rather see a more generic way of inserting URI Templates into a feed. For instance, this is an example of a syntax I've been experimenting with: <x:link-template rel="search" pattern="/feed-search?{-join|&|expr,count}"> <x:var name="expr" ref="http://.../feed-expression"; /> <x:var name="count" pattern="\d+" /> </x:link-template> Given this, assuming I understand that "http://.../feed-expression"; refers to the query spec, I could construct a query like: /feed-search?expr=(matches(title,'.*new.*'))or(matches(author,'bob.*'))&count=10 There are several use cases for embedding link-templates within feeds that would make having a generic mechanism ideal. As for RSS feeds, I would suggest that a canonical mapping of RSS to Atom be developed such that expressions written for one can be applicable to the other. I know that such a mapping would be imperfect, difficult to produce, and likely be controversial, but it would be certainly be helpful. Not having this, however, would certainly not be a show stopper. - James Brian Smith wrote: > 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 > >
