Mark Nottingham wrote:
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.
I've been asked this many times, and should probably add it as a FAQ
in an appendix. 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.
+1 this hits the same sort of complexity sweet-spot (i.e., as simple as
possible w/o being too simple + easily extensible) as Atom/AtomPub and
thus, it seems to me, has pretty good "conceptual integrity" w/ those.
-peter keane
--
Mark Nottingham http://www.mnot.net/
