Subject: Re: Fw: Possible problem in collection definition

From: Jason Crawford <[email-masked]>
Date: Sun, 19 Feb 2006 15:01:37 -0500

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

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.

---

From: Albert Lunde <[email-masked]>
Date: Sun, 19 Feb 2006 17:27:24 -0500

> term we'd need to express the second approach.  

It seems like a possible way to formalize this would be
the mathematical notion of an equivalance relation and 
equivalance classes.

If you assume a server MAY apply some notion of canonical path
equivalence (which defines an equivalence relation), then it would 
map equivalence classes of paths to resources, instead of mapping 
paths to resources.

(This is probably orthogonal to webdav's multiple bindings.)

-- 
    Albert Lunde  [email-masked]
                  [email-masked]  (new address for personal mail)
                  [email-masked] (old address)

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Feb 2006 13:39:25 +0100

Jason Crawford wrote:
> 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 

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 20 Feb 2006 07:46:17 -0700

OK, how about the following: (version 3, I believe :-)

  Although commonly a mapping consists of a single segment and a resource,
  in general, a mapping consists of a set of segments and a resource.
  This allows a server to treat a set of segments as equivalent
  (i.e. either all of the segments are mapped to the same resource,
  or none of the segments are mapped to a resource).
  For example, a server that performs case-folding on segments
  will treat the segments "ab", "Ab", "aB", and "AB" as equivalent,
  A client can then use any of these segments to identify the resource.
  Note that a PROPFIND result will select one of these equivalent
  segments to identify the mapping, so there will be one PROPFIND 
  response element per mapping, not one per segment in the mapping.

Cheers,
Geoff

"SEGMENT". 
> 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 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. 
> 
> There is a second alternative that I'd consider consistent.    We 
> can say that every equivalent segment also has a mapping to the same
> 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.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Feb 2006 16:47:08 +0100

>   response element per mapping, not one per segment in the mapping.

Perfect.

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 20 Feb 2006 13:56:43 -0800

>   response element per mapping, not one per segment in the mapping.

This seems the best version yet and I have no reservations about 
adopting the above text.

Cheers,
Elias

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 20 Feb 2006 13:59:59 -0800

> Unicode normalization forms, dropped trailing dots, whatever.

Yes.

> should be reported additionally (*).

Agreed, and I believe that we can actually require this behavior.

> other aliases to disappear (become unmapped) as well.

Of course.

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

This may be too obvious, but how about simply recommending a PROPFIND on 
the parent collection? This seems as good as any other approach to 
discover the canonical form that a server uses for identifying a resource.

Best,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Feb 2006 23:09:57 +0100

> discover the canonical form that a server uses for identifying a resource.

Discovering the canonical form may be way more complex than just doing a 
caseless comparison. How do you expect a client to actually know what 
segment it is looking for in more complex cases?

Best regards, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Mon, 20 Feb 2006 15:41:35 -0800

Should we recommend that a PROPFIND always return the same  
(canonical) segment from a given list of equivalent segments?

   Clients may be confused if a random choice from "ab", "Ab", "aB",  
and "AB" for a given set of sequential PROPFIND requests, such as  
assume that things are changing when they may in fact not have  
changed at all.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Tue, 21 Feb 2006 15:46:26 +0100

Wilfredo Sánchez Vega wrote:
> 
>   Should we recommend that a PROPFIND always return the same (canonical) 
> segment from a given list of equivalent segments?

If a server doesn't do that, UIs will behave in a *very* surprising when 
a collection view is refreshed.

Thus, I'd say, yes they SHOULD.

>   Clients may be confused if a random choice from "ab", "Ab", "aB", and 
> "AB" for a given set of sequential PROPFIND requests, such as assume 
> that things are changing when they may in fact not have changed at all.

Exactly.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 21 Feb 2006 12:07:41 -0800

On Feb 21, 2006, at 6:46 AM, Julian Reschke wrote:

> If a server doesn't do that, UIs will behave in a *very* surprising  
> when a collection view is refreshed.
>

MUST, even.

Are such segment mappings considered harmful enough to recommend that  
servers SHOULD NOT have equivalence sets of segments?  (But that if  
they do, here's how they MUST do it, of course)

Lisa

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 21 Feb 2006 14:30:16 -0800

On Feb 21, 2006, at 12:07 PM, Lisa Dusseault wrote:

>> If a server doesn't do that, UIs will behave in a *very*  
>> surprising when a collection view is refreshed.
>>
> Are such segment mappings considered harmful enough to recommend  
> that servers SHOULD NOT have equivalence sets of segments?  (But  
> that if they do, here's how they MUST do it, of course)

   These are fairly common today, and people seem to be getting by  
just fine, so I'd say no, they aren't sufficiently harmful.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Wed, 22 Feb 2006 01:11:31 +0100

>> Thus, I'd say, yes they SHOULD.

Nope. I don't think that would make sense. Servers will return 
consistent names if they can (and we tell them they SHOULD). Servers 
won't if they can't. A "MUST" won't change that.

> servers SHOULD NOT have equivalence sets of segments?  (But that if they 
> do, here's how they MUST do it, of course)

Why would that be harmful?