intertwingly

Uh, maybe a few clickable examples?

Mark demonstrates. Sam takes it a step further...... [more]

Trackback from David Czarnecki's Blog

There has been a number of posts recently about XPath search queries in URLs in true RESTian glory, inspired by the Kimbro Staken's new Syncato blog software. Some highlights:... [more]

Trackback from the iCite net development blog

Sam Ruby has added XPath query support to his blog (and presumably mombo). This is pretty damn cool, almost enough to get me interested in relearning it.

Links to Dive into Mark

Somehow this seems incorrect though, I realise it only covers links to the root of the site, but even then, surely there should be more?

Neat! Isn't this something in the path of what I and James Aylett have sketched out in the RestEchoSearchApi?

And I have to agree with Mark. A few clickabel examples would be nice. :)

Here's a few links which contain xhtml queries: pictures, code, flamebait.

Note: if any query returns more than 20 results, only the most recent 20 entries are shown.

Ah, lovely, Sam. Just lovely.

This proves what have been my point all along; that an XPath-enabled search API is extremely powerful and needed in the Atom spec.

Now, Asbjørn - I think needed is a strong word here :-)

I agree however that this is very powerful, very cool, and is certainly something that should be available in a standard way. Of course, it's not impossible we can get a REST-ian search API with this kind of power out of the door in the same time frame as an Atom core everyone is happy with ...

I'm going to have a look at making a simple GET-based, XPath-based, structure/syntax pairing in RestEchoSearchApi. That strikes me as more immediately useful (and in keeping with current implementations).

Mark also XPath-enabled his search box.

Ummm, you might not want to provide XPath searches.  I know they are powerful, but they open you up to denial-of-service attacks.

When I first started experimenting with XPath, I did something like //a//b because I wanted a 'b' which was under an 'a'.  As it turns out, this is really, really slow.  (Don't ask my why; ask someone who does the implementation.)

This can be used to DoS a server.  For example,
http://www.xmldatabases.org/WK/blog/item//a//a
times out my browser after 60 seconds.

I can't get the intertwingly.net search to handle an
XPath query so I haven't been able to test if that's
a problem here.

images in tables

James; Ok, needed is a bit strong, yes. ;-) But it's really neat.

Andrew; Great input. I haven't thought much about DoS-vulnerable queries. These queries need to be sketched out; we already have one. :) When "all" vulnerable queries have been discovered, they should be embedded into the standard, and we can give hints on what to do with them.

Having the search give an error message for all vulnerable searches is a smart thing. Many (internal) search engines need to do this for ordinary SQL queries as well, so this is nothing new. But discovering and defining all especially vulnerable XPath queries is a very good idea. Dropping XPath searches because problems exists, is not, imho.

Given the strong negative reaction from Mark when I suggested this in my first column on Atom, I can only say "neener neener neener" now. :)