capabilities lookup: it's the meta ...
jernst+lists.danga.com at netmesh.us
Wed Nov 16 09:36:11 PST 2005
Something else had been bothering me about some of the capabilities
lookup alternatives that we'd been discussing. I hadn't quite been
able to put it into words, but finally, now I know what it is ... and
I'm eager to share ;-)
FIrst, a rehash.
The operation that we are trying to define is
"given this URL, tell me what its capabilities are"
Then, an insight.
This is, if there ever was one, a "meta" traversal. Similar to
"given a Java/C#/Perl/PHP/whatever object, tell me what methods I can
invoke on it", or
"given a URL, tell me what its properties are" (like the PROPFIND
method in WebDAV)
This is not about obtaining the resource according to a different
This is also not about qualifying the GET operation of the URL with
This is a genuinely new kind of method, a "META" method, so to speak:
we are not attempting to "GET" the resource, or "POST" or "PUT" or
"DELETE" etc. -- instead, we are asking for its meta-data. (well, a
particular kind of its meta-data, namely what YADIS calls its
This is worth repeating: It is a GET, but not of the resource, but of
Maybe the best parallel, in a language such as Java, would be
"given this object, tell me what interfaces it supports". (please
interpret the word "interfaces" loosely here, on the same abstraction
level as capabilities in YADIS, I don't mean to talk about GET and
POST etc.) as opposed to "give me an HTML or TXT or Serialized
representation of the object" which would be an entirely different
kind of request.
... the conceptually cleanest way to support this "meta" operation
would be to add a new verb to HTTP ("GETMETA" comes to mind) -- like
WebDAV did. In fact, there are many parallels here because a big
chunk of what WebDAV is all about is to deal with additional meta-
data that plain HTTP knows nothing about.
... but assuming we don't want to define additional verbs for the
REST / HTTP vocabulary, which would probably be a bad idea for a
range of other reasons
... assuming that you guys agree with me that "meta" is really what
this is all about
... the engineering problem in front of us seems to be:
"given that we have a genuinely different kind of operation on a URL
than people normally do these days" (side note: I very much agree
with Mart's comment on the wiki that this capabilities/meta lookup is
going to be much more broadly useful than "just" for identity) "how
are we best going to use the means at our disposal to emulate this
Is that an accurate description of the problem?
Note that any "meta" operation (whether in YADIS or wherever) is
genuinely orthogonal to any parameters that specify which format the
client wants the response to be in. Just like in plain normal use of
HTTP, as a client I should be able to say "I like HTML better than
PDF better than TXT" (if I'm a human) vs. "I like XML only" (if I'm a
machine) for the meta-data of the URL, not just the resource behind
That's the other thing that has bothered me in the current proposals
without being able to express it so far: we seem to have assumed that
the capability query only makes sense for machine clients. But upon
reflection, I don't think so: as a human, I also want to know what a
given URL can do, and I want to know in HTML because I like it better
than PDF better than TXT and I don't like XML. (Just as an example
for the preferences of a human client).
Ergo, the "Accept" specification is, and must be, orthogonal to the
"Meta" specification (in whatever form we will settle on), in order
to be architecturally clean.
In other words, I have decided to be very much against (sorry, guys)
using the Accept header to emulate a "Meta" operation because it
collapses two orthogonal things onto the same dimension, and that is
a big no-no in the architecture book that I'm following ... because
sooner or later, we'd want to disentangle the orthogonal dimensions
and we won't be able to if we go down that route.
Can we agree on whether this is an accurate description of the
problem first before figuring out what that means for the protocol? I
would have a proposal that turns out to be only a minor
modification ... but problem description first.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051116/63df157c/lid.gif
-------------- next part --------------
More information about the yadis