[uf-rest] Roy Fielding on WebDAV and PROPs

[Dr.Ernie Prabhakar]

Hi Mark,

On Apr 11, 2006, at 7:24 PM, Mark Nottingham wrote:
> 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.

Right -- that was the original discussion about using HTTP's "Link:"  
or HTML's <link rel="properties"> to indicate server-specific  
structure.   As long as we are sufficiently clear about *what*  
structure to use in the URL, so that clients _know_ it is safe to do,  
it doesn't actually violate opacity:

http://microformats.org/wiki/rest/opacity

We obviously don't have such a spec yet, but the goal is to figure  
out what's needed to create one.   Given that ";" is a valid  
character, it might make a useful visual for such purposes. Of  
course, we'd need to bang on the idea a little more before we know  
for sure.  I just wanted to  make sure we all had a common  
understanding of what opacity does (and does not) mean.

-- Ernie P.

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