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)