Of course, it would be even better if you could not just label the source for an entire page, but if you could label a fragment of a page with its source. Heck, maybe you could start to mark up not just the underlying data sources, but also the underlying templates. Simply by marking up fragments of data, you could start building up a Javascript layer that would read these links and do inline editing on the client side.

> It’s correct that this becomes problematic when the representation to be edited is not the same as the one served by default. One way around that is a different URI space (this is what AtomPub allows, but so does WebDAV).

Ian, your proposal also uses GET to get the editable form of the resource, doesn’t it? And it uses a different URL space (in this case, URLs appended with “this-url?format=atom”), doesn’t it? So I don’t see how your proposal is any different than WebDAV in terms of meeting your objection to the way that GET is used to get source resources.

Incidentally, perhaps all of the discussion participants are already aware of this, but in case any readers are not, the old spec for WebDAV (http://www.ietf.org/rfc/rfc2518.txt) included a DAV:source property that would be attached to the “processed” URL and which would point to the “source” URL (i.e., DAV:source is analogous to Ian’s ). DAV:source was removed from the current spec (http://www.ietf.org/rfc/rfc4918.txt) due to “lack of implementation experience” — but presumably no one would complain if you used DAV:source as originally intended.

oh, and i forgot

(6) a list of all of the pages on the wiki

Also, I worked on a project awhile ago that might be slightly related, called WikiGateway (http://interwiki.sourceforge.net/cgi-bin/wiki.pl?WikiGateway), the goal of which was to provide a standard API for interacting programmatically with various different types of wiki (WikiGateway included a commandline wikiclient, a Perl library and a Python library for clients, and also gateway servers that exposed foreign wikis via WebDAV and via Atom and via XMLRPC). The project only ever worked with a handful of wiki types, and it is now a couple of years out of date (maybe in a few more years I’ll update it again..). I don’t know what similar things have been done since.

I hope that someday the various wiki implementors rally around a single standard for programmatic interaction with wikis. There was some discussion of this around 2005, but I haven’t heard much about it recently; then again, I haven’t been looking.

http://www.jspwiki.org/Wiki.jsp?page=WikiRPCInterface2

I think if you develop a standard that forces wiki servers to do more than that, people won’t implement it. In fact, even that proposal is more than what will be tolerated by most wiki programmers. I think the most you could really get all people to do is:

(1) Get HTML version of page (2) Get editable wiki text version of page (3) Get RecentChanges (4) Submit edited page (5) Identify which version/level/services of the standard is/are being provided (in a very easy-to-implement way, i.e. the server might return a number or a string or two, and maybe a list of strings (“list of services provided”), and maybe even a hardcoded XML document).

Other things that you might be able to get a substantial number of implementors to do (in my opinion): * Present RecentChanges in an Atom feed * Hardcode a service discovery document (I doubt you would convince everyone to add service discovery links to each wiki page though) * A minority might even deign to allow a “later than date X” query to limit RecentChanges. * A minority might support getting page histories and past page versions.

http://intertwingly.net/wiki/pie/WebDav

Summary for the busy:

Seems that Sam Ruby and Greg Stein, at least, worked on WebDAV before working on Atom, and Sam made a comment that may imply that he thinks of Atom as a lightweight replacement WebDAV, at least for some tasks (but I haven’t actually asked Sam Ruby if I’m interpreting him correctly).