Re: Fw: Possible problem in collection definition

Jason Crawford wrote:
> 
> 
> On Sunday, 02/19/2006 at 09:55 MST, Geoffrey M Clemm wrote:
>  >   An exception to this rule occurs if the server considers
>  >   certain segments to be equivalent (i.e., the segments will always
>  >   identify the same resource).  In this case, A MUST contain a mapping
>  >   to B from at least one of the segments that are equivalent to 
> "SEGMENT".
>  >   For example, if the server performs "case-folding" on the URL
>  >   segments, then in the preceding example, A must contain at least
>  >   one mapping to B from "blah", "Blah", "bLah", or one of the other
>  >   case-folding equivalents of "blah" (but does not have to contain
>  >   more than one such mapping).
>  >
>  > Jason also suggested that we require there to be exactly one mapping
>  > to a given set of equivalents.  I'm inclined to leave that up to the
>  > server, and only require that there be at least one.
> 
> Let me first explain what I meant...
> 
> I'm suggesting that all equivalent segments refer to the same (single) 
> mapping.  When you act on any of those segments, you're acting on the 
> same mapping.  We should also say that PROPFIND should list all bindings 

Right.

> of the collection at least once and if a binding is listed more than 
> once, the server is allowed to list a different equivalent segment for 
> each.

I'm not sure yet why we would want the server to report multiple 
equivalent segments. Use case?

> There is a second alternative that I'd consider consistent.    We can 
> say that every equivalent segment also has a mapping to the same 
> resource.  (IOW's the number of equivalent segments is equal to the 
> number of "mappings".)  We'd say if you change one mapping, the server 
> has to change the mapping at all equiv segments.  As for the  PROPFIND 
> statement above, we'd have to invent some term (for a set of equivalent 
> segments and mappings)  to express the first part of that in this 
> context.  (That's why I prefer the previous paragraph's definition.)
> Those two alternatives seem to be the only options to me.  Saying that 
> the number of "mappings" can be somewhere between 1 and the number
> of equivalent segments does not seem consistent ot me.  If we say that, 
> we have to then distinguish between (listed) mappings... and 
> [some-new-"mapping"-like-term] for the unlisted and clarify acts on each 
> and resulting behaviors of each.  This is over and above the additional 
> term we'd need to express the second approach.  
> 
> J.

I'll try to describe how I understand the problem:

1) For each path segment mapping (== binding), there may be multiple 
alias path segments that are equivalent. Use cases are case foldings, 
Unicode normalization forms, dropped trailing dots, whatever.

2) Each path segment mapping SHOULD have a canonical form that is 
reported upon PROPFIND on the parent collection, and no other alias 
should be reported additionally (*).

3) Modifying an path segment alias will affect all other aliases; for 
instance, a successful UNBIND or DELETE on one of them will cause the 
other aliases to disappear (become unmapped) as well.

4) Optimally, there would be a portable way for a client to discover the 
canonical form (**).

(*) Can we require this? From the use cases I'm aware of, I think this 
is correct.

(**) That's something I think we could define within 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-url-constraints-latest.html>.

Best regards, Julian

Received on Monday, 20 February 2006 12:42:10 UTC