It has been implemented, but not publicly.
From what I've seen, people tend to either think it hits the 80/20
point right on, or they want a *lot* more (e.g., full XQuery, YQL,
etc.).
Specific responses below.
On 14/07/2009, at 9:57 PM, Colm Divilly wrote:
Hi Mark,
yes I'd seen this before, but neglected to give you feedback on it,
I basically concur with feedback given by Brian Smith [1], James
Snell [2] previously.
* I'm not convinced of the utility of being just able to filter
within a single feed. I think a query language (e.g XQuery) that
permitted defining a feed composed of entries from many disparate
Collections of entries might be more useful.
FIQL presumes that the definition of what the target feed up is up to
its publisher, so that a collection of feeds can become a single feed
if desired.
* Don't like the prefix based selector mechanism at all, as Brian
said it goes contrary to the normal practices for dealing with
QNames. I also would prefer an XPath subset syntax.
I have little regard for QNames in general, so I don't mind abusing
them.
* The fq:interface idea has some merit, although I think James' link-
template mechanism [2] is more in line with what I had been thinking
about. Both also seem similar to Open Search [3]
* I'd like to be able to go further, in a similar fashion to how
categories can be defined in-line and out-of-line in an
app:collection element, I would like to be able to link to have a
'rel="queries"' link that links to a document that enumerates all
the queries that could be applied. This is would help reduce
duplication (where two or more feeds wish to reference the same set
of queries), and also avoid cluttering the feed when the number of
queries starts to grow large.
* I also feed that any query mechanism should be able to select on
values of HTTP headers supplied with the request in addition to any
uri parameters.
What's your use case?
A minor nit: Section 4 has the following example:
http://example.com/feed.atom?query=title==*new*,author==bob*
Shouldn't that be name==bob* ? (/entry/author/name...)
In summary I think we need a few specifications:
* The first defines a means of discovering what queries are
possible, ala link-templates or OpenSearch.
Agreed.
* The second defines a means of defining queries, It should be
possible to do this in such a way that the specification supports
multiple query lanaguages. I think of this as 'Published
Queries' (JCR has a similar concept: persistent queries [4]), a user
submits a query specification which enumerates all the 'link-
template' meta-data plus an actual query that can be processed by
the server to generate the required results, plus meta-data to bind
the parameters specified in the link-template to parameters in the
actual query.
I think that sounds interesting.
* A third specification might define a lingua-franca query language
that could be used instead of a server dependent query language, to
be used when publishing queries.
Possibly.
(Ordered from most likely to see widespread adoption to least likely)
Have you had any implementation experience with FIQL since you wrote
the draft? any insights to share with us?
Regards,
Colm
[1] http://www.imc.org/atom-syntax/mail-archive/msg20131.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg20146.html
[3] http://www.opensearch.org/Specifications/OpenSearch/1.1
[4] http://jcp.org/aboutJava/communityprocess/maintenance/jsr170/index.html
(jsr-170-1.0.1.pdf, section 6.6.11 p128)
Mark Nottingham wrote:
WRT queries, just in case you weren't aware:
http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00
Cheers,
--
Mark Nottingham http://www.mnot.net/
