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)
- 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).
Suggestions for better ways to handle these very welcome...
