Re: SEARCH by last path segment, Was: SEARCH for displayname

Lisa Dusseault wrote:

>>>property.  But it's no less feasible than other properties 
>>
>>which the 
>>
>>>server may calculate based on location/URL, possibly 
>>>'supported-live-property-set' or 'supported-method-set'.  
>>
>>E.g. I might 
>>
>>>not allow VERSION-CONTROL in some hierarchies of my server 
>>
>>and calculate 
>>
>>>whether to include it in 'supported-method-set' based on the 
>>>first-path-segment.
>>
>>In which case I'd claim that your server is broken. It's the 
>>*resource* 
>>that is version controlled or not, not it's identifier. If 
>>you think I'm 
>>wrong, please raise this on the DeltaV mailing list.
> 
> 
> Julian, please read my message.  I didn't say that the identifier
> is resource controlled.  I only said that some property values, 
> with the example of 'supported-method-set', may be calculated by 
> the server based on the request-URI.   

Yes. And I said that it's the resource that is version-controllable or 
not. That is, if there are multiple bindings to the resource, 
VERSION-CONTROL should behave the same no matter which URI you use.

> My argument isn't based on an implementation working one way or
> another, at any rate.  It's that if we say that properties have
> nothing to do with URLs, then we cut ourselves off from a useful
> set of features.  Not only the 'last-path-segment' property 
> proposed, but others, such as 'parent-url'.  We could have a 
> property listing 'other-bindings' (other than the requested 

Actually, we *do* have a DAV:parent-set property which lists *all* 
bindings to the resource. But as it lists *all* of them, it doesn't need 
to vary on the request URI.

> binding) with this model.  Properties like 'is-default-document' 
> might depend on whether the document's last path segment is
> 'default.html' or a similar value, again calculated by the

What is "is-default-document"?

> server based on the URL.  Properties like 'is-hidden' might
> apply to bindings, not to the underlying resource.

That's correct, and therefore it probably makes sense to define it where 
the state (binding) resides (this is the parent collection).

> I propose that we do not rule out properties that vary based
> on URL, when these are useful and the simplest way to specify
> a feature.  
>
> You propose that we rule out properties based on URLs but that
> will make some features harder to implement and specify.  I 
> do not see sufficient reason for that.

If making it "more convenient" means breaking an architectural 
principle, then yes, I disagree.

The WebDAV architecture talks about URI mappings being created by 
collection containment and internal member names (bindings). So 
everything that does indeed vary on the actual mapping that was used 
belongs to the state of the collection, not the resource, and therefore 
should be modelled as a property of the collection.

If this means that things get hard that would otherwise be simple, let's 
fix *that* instead of working against the underlying architecture.


Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 18 November 2003 15:37:26 UTC