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