RE: Adv Coll review

Thanks for your comments, Jason. Responses interspersed below.

> -----Original Message-----
> From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com]
> Sent: Tuesday, July 20, 1999 8:14 PM
> To: w3c-dist-auth@w3.org
> Subject: RE: Adv Coll review
> 
> 
> 
> 2 - Notational Conventions
> 
> Reference - this definition is too specific to one meaning of 
> this term.  Just
> skip defining "reference".  (Caveat: I haven't read the whole spec.)

The discussions that motivated defining "reference" have been removed from
the spec, so I agree that we could also remove the definition, except that
...

> 
> Ordinary Resource - This term is poor because it doesn't say 
> in what way the
> resource is ordinary.  Secondly, I think the definition might 
> be wrong... but if
> it is right, then the ugly term "non-reference resourc" would be more
> descriptive.

There are some discussions that contrast "ordinary resources" with
"references".  I'm happy to replace "ordinary resource" with "non-reference
resource", but then we do need to define "resource" in order to understand
what a "non-reference resource" is.

I like the definition of "reference" that is currently in the spec: "A
resource whose purpose is to provide access to another resource."  It has to
encompass redirect references and (in case we ever add them) direct
references, strong and weak references (in case we ever add support for
referential integrity), and it has to exclude bindings.  I think the
definition does that.  If it is more restrictive than usage in other
contexts, I don't care about that.

That said, if you have in mind a different definition that meets the
constraints I listed, we should consider it.  Geoff likes to think of
references as resources that instantiate a relationship between two URIs, so
maybe we could consider that as a definition.

> 
> 
> 4.1 Shared Resources -- Overview
> 
> "HTTP and WebDAV servers already provide URI mappings, so 
> there is little extra
> work involved in allow clients to create them."  -- I don't 
> understand this.
> How do HTTP and WebDAV do this?

HTTP and WebDAV servers do map absolute URIs to resources.  How they do this
is up to them.  It can be through configuration files that define mappings
from request-URIs to file system locations, together with the capabilities
of the underlying file system.

> 
> "A limitation of bindings is that a server would need proxy 
> capabilities in
> order to support. bindings to resources on another server.."  
> -- I don't know
> what is meant by "proxy capabilities", but I can think of 
> ways to do it that
> using out of band communication between servers that don't 
> involve anything that
> I'd think of as a "proxy" of any sort.  I do agree with the 
> conclusion though.
> 

I think you are right here.  We should not say that proxy capabilities are
needed, but rather that out-of-band communication between servers would be
needed.

> 
> 
> 4.2 Bindings
> 
> first sentence -  I believe that sentence needs the word URIs 
> replaced with "URI
> segments".

I'm not seeing the sentence you reference.  Are you looking at 03.4 revision
of the spec?  I think the first paragraph under 4.2 (which Jim drafted)
gives an admirable explanation of the relationship between bindings, URI
segments, resources, and internal member URIs that makes it clear how what
we say about bindings relates to what rfc 2518 says about internal member
URIs.

> 
> second paragraph - don't use index.html in the example.  
> URI's with that name
> typically have side effects that might cause the user to be confused.

OK

>    -- My margin notes also note that  I'm confused by this 
> paragraph.  I'm not
> going to reread it now unless requested.  I'd rather save my 
> fresh "first time"
> mind.
>    -- I did understand enough to think that where it says 
> that "two" bindings
> are created that the truth might actually be "zillions" of 
> bindings are created.
> I recall that the paragraph didn't tell me enough to pick a 
> specific number.

We're trying to distinguish between bindings and URI mappings, and to show
how creating a single binding can result in multiple new URI mappings.

We can try to tighten up the description of the example.  Based on the
information given, we can only identify 2 URI mappings for each resource,
but there might be others in addition.

> 
> third paragraph - "For a resource implemented by a 
> computer..." -- Ummm... if
> we're going to say "implemented by a computer" then we should 
> explain what the
> alternative is.  As far as I know, all resources are 
> "implemented by a computer"

I'd be happy to get rid of the qualification, but Jim may have something
particular in mind here.  That a resource doesn't have to exist online?

> 
> paragraph after the diagram - The second sentence I believe 
> talks about the
> previous paragraph and the first sentence is unrelated and 
> actually is a new
> thought not even related to the diagram.
> 

We could get rid of the first sentence, which gives a capsule definition of
"resource".  Since a resource appears in the diagram, it's not altogether
irrelevant, but it might lead you to expect to see entities in the diagram,
and we removed those.

> paragraph beginning "The identity of a binding is determined 
> by the URI segment
> (in it's collection) and the resource that the binding associates."
>    -- interesting definition.  Something makes me 
> uncomfortable making this
> definition... but I haven't read whole spec so this 
> definition might be
> necessary later.

A binding is a relationship between a URI segment in a collection and a
resource.  We want to say that both the URI segment and the resource are
essential to the relationship.  If you change either one of them, the
relationship (binding) goes out of existence and is replaced by a different
relationship (binding).

This affects the way we describe BIND with a request-URI of an existing
binding.  We don't say that it updates the existing binding, but that it
replaces that binding with a new binding.

It also affects the way we talk about the integrity of bindings. In a sense,
it is impossible for the integrity of a binding to be compromised. It can't
happen that a binding that once associated /X/Y with resource R comes to
associate /X/Y with a different resource R' or no resource as a side effect
of some operation on another binding.  But what could happen is for the
binding to be destroyed as a side effect of some operation on another
binding.  So when we require that the integrity of bindings be guaranteed,
we say that servers have to insure that bindings cannot be destroyed as a
side effect of an operation on another binding.

>   -- second sentence of this paragraph talks about the 
> resource being destroyed.
> I don't like this.  The resource can't be destroyed within 
> the protocol.  It can
> only be dereferenced... so saying this right here early in 
> the document is a
> distraction.  If we want to talk about out of band 
> destruction, we can talk
> about it as a caveat after we've established the basic 
> concepts..    Just
> introducing the possibility here is distracting.

Let's say "If the resource goes out of existence, the binding goes out of
existence."

Some rewording also has to be done 2 paragraphs later.

> 
> next paragraph - the phrase "where a binding resides" is 
> misleading at first.
> For one thing, the antecedent of that phrase is not clear.  
> It could be saying
> that the it's notifying a server OF where a binding resides.  
>  Yes, the word
> "of" isn't in there, but it still can be misleading.    
> Perhaps we can say
> ."...notifying a referencing server of the change."

I agree we should reword this, but I don't want to use the expression
"referencing", since bindings are not references in our usage of those
words.  Maybe "...notifying some server that manages a binding to the
resource."

> 
> 4.2.2 Bindings to Collections
> 
> paragraph one, last last sentence -- REally.  It must respond 
> with 506 Loop
> Detected?  Even if they are benign subloops?

I'm not seeing how a loop could be benign for a Depth: infinity request.
The kind of case we had in mind was:
B1 is a binding to collection C1, which contains a binding B2 to collection
C2, which contains a binding B3 to collection C1.

What kind of case were you thinking about?

> 
> paragraph two -- "that collection accessible via a new URI, 
> but "    I believe
> "a" needs to be replaced by "one (or more)" to be technically 
> correct..

OK

> 
> 4.2.3 URI Mappings Created by BIND
> -- I found this formula very confusing.  Starting with step 
> 4.  For one thing
> "next" doesn't mean anything to me the first time I read it.
> 

We'll look at trying to simplify this discussion.  It is just trying to give
a precise description of the set of URI mappings induced by the creation of
a new binding.  Geoff also thought a simpler definition could be given.

> 
> 4.2.4 - An example like this could be very useful for 
> resolving the confusion in
> 4.2.3, but since the URI's involved are only one level down 
> from the base URI,
> it's not clear how this works in the general case.  Let's 
> also say that 1/2/ and
> one/two/ and 1/2/xxx.html also exist and then step through 
> the example.
> 
> I haven't read further than this.  I will for the next 
> version.  One comment
> though
> 
> I recognize people's comments that we should break this spec 
> into three parts.
> I'd be happy if we'd just define levels of advanced 
> collections within this
> spec.  And I suspect that bindings and indirect references 
> should be left
> together just so that we insure that we don't develop 
> conflicting vocabulary.
> 

I think the only reason we opted to keep a single spec was a pragmatic one
-- that it would be easier to get a single spec to Proposed Standard than
several separate ones.

We currently define 2 compliance classes in this spec: one for ordering, and
one for shared resources (bindings + redirect references).

> 
> J.
> 
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com
> 
>

Received on Friday, 30 July 1999 12:40:36 UTC