Re: Exploring a new WG around Atom

[Mark Nottingham <[e-mail]>]

It has been implemented, but not publicly.

 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.).

Specific responses below.


On 14/07/2009, at 9:57 PM, Colm Divilly wrote:

> Hi Mark,
> 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.

FIQL presumes that the definition of what the target feed up is up to  
its publisher, so that a collection of feeds can become a single feed  
if desired.


> * 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.

I have little regard for QNames in general, so I don't mind abusing  
them.


> * 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]
> * 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.
> * 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?

>
> A minor nit: Section 4 has the following example:
> http://example.com/feed.atom?query=title==*new*,author==bob*
> Shouldn't that be name==bob* ? (/entry/author/name...)
>
> In summary I think we need a few specifications:
>
> * The first defines a means of discovering what queries are  
> possible, ala link-templates or OpenSearch.

Agreed.

> * 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.

I think that sounds interesting.

> *  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.

Possibly.


> (Ordered from most likely to see widespread adoption to least likely)
>
> Have you had any implementation experience with FIQL since you wrote  
> the draft? any insights to share with us?
>
> Regards,
> Colm
>
> [1] http://www.imc.org/atom-syntax/mail-archive/msg20131.html
> [2] http://www.imc.org/atom-syntax/mail-archive/msg20146.html
> [3] http://www.opensearch.org/Specifications/OpenSearch/1.1
> [4] http://jcp.org/aboutJava/communityprocess/maintenance/jsr170/index.html 
>  (jsr-170-1.0.1.pdf, section 6.6.11 p128)
>
>
>
> Mark Nottingham wrote:
>>
>> WRT queries, just in case you weren't aware:
>>  http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00
>>
>> Cheers,
>>
>>
>


--
Mark Nottingham     http://www.mnot.net/