On 21/07/2009, at 12:14 AM, Colm Divilly wrote:
Mark Nottingham wrote:
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.).
:) Feels like I'm falling in the latter group, but I think it
wouldn't need much changing to make me happy:
To recap, FIQL does the following:
- enumerates the available queries
- for each query enumerate the parameters for the query
- for each parameter enumerate its type
- for each parameter define how it 'selects' from the feed.
It is this last bullet that I am concerned with, I'm not convinced
that a query definition needs to tell clients how the query selects
from the feed. Were there particular use cases that would be
inhibited by the client not knowing how selection happens? Any
reasons the following would not suffice ?
<fq:interface
xmlns:fiql="http://purl.org/syndication/query";
template="/feed-search?{-join|&|title,foo,bar}">
<fq:param name="title"/>
<fq:param name="foo"
type="http://purl.org/syndication/query/date"/>
<fq:param name="bar"
type="http://purl.org/syndication/query/numeric"/>
</fq:interface>
In the above example the query interface just describes the inputs
to the query but says nothing about how those inputs are applied to
generate a result, the name attribute is no longer overloaded with a
'selector' semantic.
If a feed provider wishes to advertise how query parameters are
bound to entry elements/attributes they could include a fq:param/
@path attribute in order to communicate that information.
Regards,
Colm
* 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?
Just a couple of messy things:
- Query needs to re-write URIs and/or xml:base decls in the
response, depending on the value of a custom HTTP header (in order
to re-write URIs to their publicly accesible endpoints)
Hmm. Probably best to do it on the client side, or with a URI query
parameter...
- Query needs to filter results based on user identity, which is
provided by means of yet another custom HTTP header (provided by a
web SSO mechanism).
I think this is more about feed selection (usually by the URI) than
actual query processing...
Cheers,
--
Mark Nottingham http://www.mnot.net/
