On 20/12/2007, at 9:58 PM, Sylvain Hellegouarch wrote:
Hi Mark,
I was following the discussion around this draft you've proposed and
rather than focusing on the choice of the most appropriate query
language used I wanted to ask you about the purpose of this draft?
Who is the target? Since you use URI-like query, are you thinking of
public services to query Atom feeds? In such case, shouldn't the
draft have a large security section (it looks like creating yet
another query syntax means that its security is by default nil until
proven otherwise)? Are you planning on making the draft
informational only or more?
Great questions.
I started this after looking at GData, which is really just APP +
proprietary auth + proprietary feed-focused query. Auth is a hard and
luckily separable, but looking at the query portion of things, I
thought we could do better.
So, yes, I'm thinking of public services, definitely. Yes, security
considerations need to be filled out. Informational is the most I'd
aspire to (unless there's *significant* interest in going further),
and that may be too far.
No matter what, FIQL will never be able to describe all the use
cases of querying an Atom document and therefore will create a
stress in an application which will have to make the decision about
either dropping FIQL entirely in favor of home made XPath/XQuery/
etc. queries or will potentially extend FIQL.
Nor should it try to do everything; it's all about making the most
common 80% as easy as possible to implement and use. That said, I
tried to make sure that it is extensible in the right places.
Overall, I'm not convinced there is a need for such specification.
It might be great as best practices on the Atom wiki however. Also,
even though some topics need an IETF draft, I'm worried that by
defining specialized ones for Atom when standard alternatives
already exist (e.g. XPath) the community will attract concerns about
its capacity to re-use existing solutions.
Perhaps, but if that's the case, why aren't people slapping generic
XPath engines in front of their feeds? Why did Google choose to go for
their own syntax instead of using XPath? Yes, FIQL is a new syntax,
but it's one that people can understand after sitting down and playing
with it for a few minutes. XPath 2.0 doesn't have the same property.
A lot of the discussion to date has been around the query language
itself. To me, the most important part of FIQL is fq:interface; having
a way to declare that there is a query interface -- whatever the query
syntax -- is IMO necessary if people are going to be exposing these
things.
That being said I'm not criticizing your work Mark, as I said just
as a best practices document such specification would be very
valuable to the community. But trying to go the IETF way sometimes
feel too heavy.
To be clear, I submitted this not because I'm sure I want to
standardise it; I did so because I want feedback from this community
on this particular proposal, and to generally gauge interest in an
openly defined feed query language.
Thanks!
--
Mark Nottingham http://www.mnot.net/
