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

> > 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.  

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 
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
server based on the URL.  Properties like 'is-hidden' might
apply to bindings, not to the underlying resource.

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.

Lisa

Received on Tuesday, 18 November 2003 15:19:20 UTC