Remember, not everything will be HTML; that's one reason why it's
preferable in HTTP. Also, a generic implementation might not know
anything about your content's format, but it will know about HTTP
headers.
On 2006/04/11, at 4:20 PM, Dr. Ernie Prabhakar wrote:
Hi Dan,
On Apr 11, 2006, at 3:56 PM, Dan Kubb wrote:
The interesting question for me is what the "right" way to do
properties would be over HTTP. I presume it would require some
sort of convention for a property namespace, which implies non-
opaque URLs. Which in term (in order to be RESTful) would
require the *server* to have some way to tell clients about it,
since clients shouldn't *assume* URI structure.
I was thinking that the Link header from RFC 2068 would be a good
fit for this. There's a note at the end of RFC 2616 that it was
obsoleted because it wasn't widely implemented.
Thanks, a very interesting point. I was particularly intrigued by:
The Link field is semantically equivalent to the <LINK>
element in HTML.[5]
The question then becomes, is this better to implement in HTTP
(where it is available for the entire site, a la WebDAV), or in the
HTML (e.g., <link rel="properties">).
I'd lean towards the latter, as it seems more in keeping with
Microformats philosophy, as well as being easier for clients to
parse and interpret. Any reason to prefer it in HTTP? If not, we
might want to look into a relProperties microformat...
-- Ernie P.
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
--
Mark Nottingham
[EMAIL PROTECTED]
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
