[uf-rest] Roy Fielding on WebDAV and PROPs

[Mark Nottingham]

If your site chooses to use the semicolon in this fashion, certainly.  
However, "standardising" on that would break URI opacity, as this  
isn't defined in the generic syntax or in the HTTP scheme. Existing  
sites can and do use the semicolon for other purposes; e.g., matrix  
URIs.

Cheers,



On 2006/04/11, at 5:22 PM, Breton Slivka wrote:

> rfc2396 briefly mentions in section 3.3:
>
> "The path may consist of a sequence of path segments separated by a
>    single slash "/" character.  Within a path segment, the characters
>    "/", ";", "=", and "?" are reserved.  Each path segment may  
> include a
>    sequence of parameters, indicated by the semicolon ";" character.
>    The parameters are not significant to the parsing of relative
>    references."
>
> it further mentions
>
> "Extensive testing of current client applications demonstrated that
>    the majority of deployed systems do not use the ";" character to
>    indicate trailing parameter information, and that the presence of a
>    semicolon in a path segment does not affect the relative parsing of
>    that segment.  Therefore, parameters have been removed as a  
> separate
>    component and may now appear in any path segment.  Their influence
>    has been removed from the algorithm for resolving a relative URI
>    reference.  The resolution examples in Appendix C have been  
> modified
>    to reflect this change."
>
> It doesn't seem to go into much more detail about what a  
> "parameter" is, so I will assume for now (unless someone can find  
> the relevant documentation on this) that it is up to the specific  
> application to determine the usage for these paramaters. THEREFORE,  
> one can use semicolon parameters to retrieve properties from  
> resources like so
>
> http://www.hostname.com/database/ 
> object;property1;property2;property3/ 
> subobject;property4;property5;property6
>
> it is possible then, to standardize on at least one parameter name  
> which would return a list of available properties, or simply return  
> all available properties. Individual properties can be retrieved  
> using URI scheme as above.
>
> HOW these properties are returned to the client is another matter.  
> Whether it is through metatags, or header information, I have no  
> idea which is best. But I thought it would be somewhat useful to  
> the conversation to throw in that oft forgotten and unused reserved  
> character in URI naming schemes: The semicolon.
>
>
>
>
>
> On Apr 11, 2006, at 3:32 PM, Dr. Ernie Prabhakar wrote:
>
>> I've always felt there was something wrong with WebDAV, and Roy  
>> did a nice summary of what over on rest-discuss:
>>
>> On Apr 11, 2006, at 12:40 PM, Roy T. Fielding wrote:
>>> PROP* methods conflict with REST because they prevent
>>> important resources from having URIs and effectively double the
>>> number of methods for no good reason.  Both Henrik and I argued
>>> against those methods at the time.  It really doesn't matter
>>> how uniform they are because they break other aspects of the
>>> overall model, leading to further complications in versioning
>>> (WebDAV versioning is hopelessly complicated), access control
>>> (WebDAV ACLs are completely wrong for HTTP), and just about every
>>> other extension to WebDAV that has been proposed.
>>
>> 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.
>>
>> Any thoughts about the optimal way to do that?
>>
>> -- Ernie P.
>>
>> _______________________________________________
>> microformats-rest mailing list
>> microformats-rest at microformats.org
>> http://microformats.org/mailman/listinfo/microformats-rest
>
> _______________________________________________
> microformats-rest mailing list
> microformats-rest at microformats.org
> http://microformats.org/mailman/listinfo/microformats-rest
>


--
Mark Nottingham     http://www.mnot.net/