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