Xpath enabled query

The search box now accepts queries that start with a "/" and refers to elements in either the xhtml or atom namespaces.  The result is the set of posts (in reverse chronological order) that either match the query or have a comment that matches the query.


Uh, maybe a few clickable examples?

Posted by Mark at

It's all about the XPath query

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

Trackback from David Czarnecki's Blog at

XPath URLs and web searches

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 at

XPath Queries

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.

... [more]

Trackback from insom.me.uk at

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?

Posted by Aaron Brady at

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

Posted by Asbjørn Ulsberg at

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.

Posted by Sam Ruby at

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.

Posted by Asbjørn Ulsberg at

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

Posted by James Aylett at

Mark also XPath-enabled his search box.

Posted by David Czarnecki at

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.

Posted by Andrew Dalke at

images in tables

Posted by Sam Ruby at


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.

Posted by Asbjørn Ulsberg at


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

Posted by Rich Salz at

Add your comment












Nav Bar