Subject: WebDAV Bindings - Issue Yaron.5.3Huh?

From: Yaron Goland <[email-masked]>
Date: Sun, 16 Jan 2000 17:51:50 -0800

The first paragraph of section 5.3 reads "Suppose a BIND request causes a
binding from "Binding-Name" to resource R to be added to a collection, C.
Then if C-MAP is the set of URI's that were mapped to C before the BIND
request, then for each URI "C-URI" in C-MAP, the URI "C-URI/Binding-Name" is
mapped to resource R following the BIND request." 
	I have a B.S. in CS & EE and got A's in my classes on set theory and
I still can't read this paragraph. I tried over and over again and I just
couldn't figure it out. If you are going to try to write set theory in
English you should at least translate it faithfully using the appropriate
terms such as "for all" and "there is an instance of". Personally I would
recommend just using an ASCII version of set code notation. Whatever you do,
the current paragraph MUST go. It is unfathomable. In fact here is the best
translation I have been able to come up with: Imagine I have a collection
http://icky/bop which contains http://icky/bop/blah. Imagine I now want to
map http://zizbang/rocky to http://icky/bop/rack. According to this language
it would seem I would have to create a bind to http://icky/bop/blah/rack. I
know this makes no sense but I swear that is what the sentence seemed to
mean when I tried to read it four or five times. As such I move that the
paragraph be rewritten.

---

From: "Slein, Judith A" <[email-masked]>
Date: Fri, 21 Jan 2000 16:43:21 -0500

What we were trying to accomplish in 5.3 and 5.4 was to state concisely and
reasonably formally exactly what new URI mappings are induced when a new
binding is created.
 
Recalling that a binding is a relation between a segment S in a collection C
and a resource R, the story is basically this.  Take every URI that maps to
collection C.  Concatenate S to that URI as its final segment.  Each URI you
create in this way is a URI that now maps to R in virtue of the new binding.
 
That's it unless R is itself a collection, in which case for every
descendent of R there is a new URI mapping for each of the new URI mappings
to R itself.
 
It seems to me that the current language in the spec is pretty clear (it's
certainly a vast improvement over what was in earlier drafts).  I doubt if I
can do any better, but let me take another stab at it and people can say
whether they think it helps:
 
5.3 URI Mappings Created by a BIND
 
This section describes the set of new URI mappings that result from the
creation of a new binding to a resource.
 
As defined in Section 3 above, a binding is a relation between a path
segment S in a collection C and a resource R.  We represent this binding as
C:(S->R).  The creation of this binding induces new URI mappings to R as
follows:
 
For each URI "C-URI" that was mapped to collection C before the BIND
request, the URI "C-URI/S" maps to resource R after the BIND request has
been processed.
 
For example, suppose that before the BIND request, the following URIs map to
collection C:
 
http://www.fuzz.com/A/1 <http://www.fuzz.com/A/1> 
http://fuzz.com/A/one <http://fuzz.com/A/one> 
 
Then a binding from segment "foo" to R is added to collection C.  The
creation of this binding causes the following URIs to be mapped to resource
R:
 
http://www.fuzz.clm/A/1/foo <http://www.fuzz.clm/A/1/foo> 
http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> 
 
In addition, if R is itself a collection, then additional URI mappings to
the descendents of R result from the creation of the new binding to R.  For
example, if R already contained the bindings R:("bar"->R1) and
R:("bat"->R2), then the following new URI mappings to R1 and R2 are induced:
 
http://www.fuzz.com/A/1/foo <http://www.fuzz.com/A/1/foo> /bar
http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> /bar
http://www.fuzz.com/A/1/foo <http://www.fuzz.com/A/1/foo> /bat
http://fuzz.com/A/one/foo <http://fuzz.com/A/one/foo> /bat
 
Note that if a loop is created by adding to a collection C a binding to C
itself or a parent of C, an infinite number of new URI mappings is created.
For example, if the binding C:("myself"->C) is created in collection C, the
following infinite number of URI mappings to C are induced:
 
http://www.fuzz.com/A/1/myself <http://www.fuzz.com/A/1/myself> 
http://www.fuzz.com/A/1/myself/myself
<http://www.fuzz.com/A/1/myself/myself> 
...
http://fuzz.com/A/one/myself <http://fuzz.com/A/one/myself> 
http://fuzz.com/A/one/myself/myself <http://fuzz.com/A/one/myself/myself> 
...
 
As well as an infinite number of new URI mappings to other members of C,
like
 
http://www.fuzz.com/A/1/myself/foo <http://www.fuzz.com/A/1/myself/foo> 
http://www.fuzz.com/A/1/myself/myself/foo
<http://www.fuzz.com/A/1/myself/myself/foo> 
...

- -Judy

 -----Original Message-----
From: Yaron Goland [mailto:[email-masked]]
Sent: Sunday, January 16, 2000 8:52 PM
To: [email-masked]
Subject: WebDAV Bindings - Issue Yaron.5.3Huh?

        I have a B.S. in CS & EE and got A's in my classes on set theory and
I still can't read this paragraph. I tried over and over again and I just
couldn't figure it out. If you are going to try to write set theory in
English you should at least translate it faithfully using the appropriate
terms such as "for all" and "there is an instance of". Personally I would
recommend just using an ASCII version of set code notation. Whatever you do,
the current paragraph MUST go. It is unfathomable. In fact here is the best
translation I have been able to come up with: Imagine I have a collection
http://icky/bop <http://icky/bop>  which contains http://icky/bop/blah
<http://icky/bop/blah> . Imagine I now want to map http://zizbang/rocky
<http://zizbang/rocky>  to http://icky/bop/rack <http://icky/bop/rack> .
According to this language it would seem I would have to create a bind to
http://icky/bop/blah/rack <http://icky/bop/blah/rack> . I know this makes no
sense but I swear that is what the sentence seemed to mean when I tried to
read it four or five times. As such I move that the paragraph be rewritten.

---

From: Yaron Goland <[email-masked]>
Date: Sat, 22 Jan 2000 23:13:10 -0800

Sigh... the language still makes my head hurt. However I think we have
reached put up or shut up time. Either I have to come up with better
language or I have to go away.

Please note, for those new to the IETF, that there is no general "Put Up or
Shut Up" requirement for last calls. It is completely legitimate for someone
to come to a last call and say "This language sucks" and to stop the draft
until the group agrees on better language. There is absolutely no basis for
asking that person to put in better language. After all they are not an
author and therefore are not normally qualified to write up new language.
However they are a customer and if they can't understand the language then
it means the authors have work left to do.

That having been said my relationship with the authors of the Bind spec is
not one of innocent bystander (more like accident victim ;) and I owe them
collectively so many favors that it isn't even funny. Currently they are
suffering from "been working on this @*!$*@# spec for too @*!$*@# long"
disease and so have trouble fixing language that appears perfectly rational
to them but looks like near gibberish to the rest of humanity. As such I
have something of a duty to help out by taking a fresh perspective and
hopefully using that perspective to produce clearer language.

But here is where I have to ask for forgiveness. There was a family
emergency that has caused me to fly off to Israel at the last second. In
fact, I am currently typing this letter from Israel. As such I don't have
time right now to re-write the language. Doubly unfortunately I have a super
critical presentation to give to my boss's boss's boss's boss's boss on the
1st. So as soon as I get back to the states my life must be dedicated to
that presentation. This means that I won't have time to produce alternate
language until the week of the 1st. I normally wouldn't ask for so long but
the family emergency has really screwed everything up.

I sincerely apologize for the delay.

> From: Slein, Judith A [mailto:[email-masked]]
> Sent: Friday, January 21, 2000 11:43 PM
> To: 'Yaron Goland'; [email-masked]
> Subject: RE: WebDAV Bindings - Issue Yaron.5.3Huh?
> 
>