[uf-rest] Roy Fielding on WebDAV and PROPs

[Mark Nottingham]

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
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest
>
>

--
Mark Nottingham
mnot at yahoo-inc.com