hello.
Colm Divilly wrote:
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.
i do agree that a feed query language should be able to do that, but not
in the sense that it actually takes multiple feeds as input. you can
always aggregate feeds into one feed, retain their source information,
and then query that aggregate feed. there are two main advantages to
this approach:
- aggregation and querying are independent, and you can chain and
combine both as you like. since feeds have the built0in ability to be
aggregated, there is no need to replicate that in the query language.
- by using only one feed as input it is easily possible to use a query
in the feed's URI. you loose that ability if you can have multiple
feeds, and i think this is a feature that is very powerful.
* 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.
same here. more importantly, FIQL is operating very much on the feed
syntax level. i think we need something like a "feed infoset", i.e. an
abstract data model of a feed that does ignore certain syntax issues.
also, in the end i'd like to see a language that essentially would be a
"collection query language", because in the end, you don't really query
the feed, but the underlying collection, and you get the query results
as a feed.
wrt prefixes and namespaces: XML namespaces always are hard to deal
with. my approach is to assume that the prefixes used in the feed can be
used as defined by the feed, but that queries can also define their own
prefixes and use those. this is a bit brittle if feeds change their
namespace declarations, but that will not happen too often.
* 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]
some sort of "service description" of a feed definitely is very useful,
so that services can publish what sort of query they support. it may be
something as simple as a simple keyword search (a la opensearch), or it
may be something as complex as a join spanning multiple entries.
* 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.
nice idea, "feed query interfaces" thus would become standalone documents.
* 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.
hm. i am not sure about this one, even though i see that it might be
convenient. one of the things i think should happen for a feed query
language would be to rather see it as a collection query language and
make it a little less dependent on the exact feed syntax. allowing HTTP
into the language would couple it more tightly with its implementation
details. we might consider a magic prefix, though, that (unless it is
bound to something else) could be used to select HTTP parameters in the
query.
* The first defines a means of discovering what queries are possible,
ala link-templates or OpenSearch.
part of that would be to first define the data model we are querying on.
in essence, it would be the infoset or XDM for feeds, and i think in the
long run, we really need something like that. tools like the universal
feed parser give you some similar to such a model, but these models are
tool-specific, and sometimes not very convenient (the universal feed
parser, for example, has no standard way how to expose extensions). i
think we should have such a "feed infoset" first, but my guess is that
some might see that as too much of a top-down approach.
* 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.
that would be the query language operating on the feed infoset, right?
if we think in XML terms, this would be XPath. the input of such a
language should be a feed infoset, the output probably one as well.
* 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)
i would see that the third thing might be the query interface that would
allow providers to publish query templates, if they wish to do so. this
might be particularly important for all the query parameters that
providers might support that are not represented in the feed itself, but
should be queryable anyway.
cheers,
erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
[email protected] - http://dret.net/netdret
UC Berkeley - School of Information (ISchool)
