Possible problem in collection definition

On Sun, Feb 19, 2006 at 03:01:37PM -0500, Jason Crawford
wrote:
> 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.  

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  albert-lundenorthwestern.edu
                  atlundepanix.com  (new address for
personal mail)
                  albert-lundenwu.edu (old address)

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

Geoffrey M Clemm wrote:
> 
> 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

Perfect.

Best regards, Julian

Geoffrey M Clemm wrote:

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

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


Cheers,
Elias

Julian Reschke wrote:

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

Yes.

> 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 (*).

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

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

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

   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


On Feb 20, 2006, at 7:47 AM, Julian Reschke wrote:

> Geoffrey M Clemm wrote:
>> 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
>
> Perfect.
>
> Best regards, Julian

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.

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

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

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