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.
* 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.
* 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.
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.
* 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.
* 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.
(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,
