RE: Adv Coll review

I've started going through the Adv Coll document..  I got a bit bogged down and
I'm not going to restart again until the next version since I feel I'm more
thorough the first time through it and I don't want to waste the
"first-time-ness" context if there is going to be another release that includes
a lot of fixes to address a lot of concerns that Yaron apparently had.

Here are my comments...


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

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.


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?

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



4.2 Bindings

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

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

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"

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.

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

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

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?

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

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.


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.


J.

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

Received on Tuesday, 20 July 1999 20:14:33 UTC