RE: Adv Coll review

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

It is important to understand what a resource is.  I already understand what
one is, so I don't have a good perspective on whether we need to devote much
space defining "resource".  The definition in an earlier RFC that Jim often
references works for me as long as we dedicate time defining bindings...
which I think we do.  I guess it's also important to be clear if we feel
references are attributes of resources or of URI's.  It looks we have put
this stake in the ground here.  We say they are characteristics of resources.
The next time I review the spec, I'll have to keep this in mind.


> 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.
Interesting.  I don't even want to think about these other reference types
right now.  It makes my brain hurt trying to think how they might come
back into the spec. :-) -- When I read this definition of "reference" I
have to admit it didn't occur to me that it excluded bindings.  I don't
know if knowing this is important enough to bring attention to this there.
Once again, when I review the spec again, I'll keep this in mind.

I guess technically I'd like the term "reference resource" to contrast
with "non-reference resource".   Of course the heat of active discussions,
I suspect the word "resource" will be elided... but as far as the spec
goes, my preference is to include the word "resource".  -- I can imagine
(because I've already done it in a server that predates WebDAV)
that as WebDAV evolves, we're going to see properties that have values
that *reference* resources.  If we start typing values, we're going to
be very tempted to use the word "reference" there too.  I'd like to
keep the official wording distinctive for this reason.



> 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.
No.  The definition is fine for now.  I just never thought of references as
actually being associated with the resource.  I'll try that model on for size
when I next review the spec.


>> 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.
Yes, but how they do it now will determine how difficult it will be to leverage
their current mapping schemes to the new semantics.  Current server's schemes
tend to be trivial.  They aren't necessarily condusive to BIND semantics.  Sure,
GET processing will be able to reuse much of the existing code.  But
UNBIND/DELETE and
MOVE could pose a performance problem for those implementations since they'll
have to look for aliasing.    I just feel that saying what we're saying will
trivialize the task or perhaps encourage implementors to try to leverage the
existing implementation when that may not be optimal.



>> 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.
I'm looking at draft-ietf-webdav-collection-protocol-04 which is what
I think you meant.  It says...

   Bindings are part of the state of a collection. In general,
   there is a one-to-one correspondence between a collection's
   bindings and its internal member URIs.

This of course takes us back to look at our definition of "Internal
member URI".  I think I am mistaken as I look at that.  I thought
it was suggesting that a collections state (implementation) should
consist of a set of internal member URI's.

As I read further I do see something that seems odd...

   The final segment of each internal
   member URI identifies one of the bindings that is part of the
   collection's state, unless the internal member URI is not bound to a
   resource.

Is it possible for an internal member URI not to be bound to
a resource?   (BTW, it's interesting that we say "bound" here
and not "mapped" since we are talking about URI's... not URI
segments.)




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

Sounds fine.  I was being too picky.


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

If a tree falls in the forest...?   I think it's a significant distraction.


> > 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.
What got my attention was that the diagram shows many URI's mapping to
a resource and my quick reading of that took it to talk about a single
URI mapping to multiple resources... which is not what the diagram shows.
My reading of course was not strictly correct, but I don't think that first
sentence is not really helpful given the diagram doesn't show entities and we
don't talk about entities anywhere else.  If we want to define resource,
we can do that at the top of the document where all the other definitions are.
And if we do that, I think we should just reference the rfc that's dedicated to
that. Anyway, bringing entities into this here seems distracting.  Especially
for just a single sentence.


>> 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).
Sounds fine.  I can't explain my nervousness.  This at least makes the
definition clear.  When I review the spec again, I'll try to notice if the rest
of the document is consistant with this.


> 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.
Sounds fine I guess.  I'm still uneasy though. My tendency is to think of all
this from a collection-centric implementation perspective whereby the binding is
identified by the collection and member URI segment.  And that the value of the
binding is the is a pointer to a resource via some unspecified mechanism.  And
integrity is a matter of a breakdown in that unspecified mechanism.  As I said,
your approach of saying the binding is the 3-ple sounds simplier as far as the
spec goes.  I'll try it on for size.


>>   -- 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."
I remain uncomfortable with this... but I see what you are trying to do and I
don't have a suggestion at hand.

Some rewording also has to be done 2 paragraphs later.


> 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."
I'm not sure about "some", but I think you've got the right idea. :-)

>> 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?
The same but... where the root of the infinite tree (specified by the request
URI) is C4 and not involved in the loop.  C4 might have a C1 as a member for
example and the loop lies entirely within the tree.  If the server can deal with
this, I don't see a reason for returning an error code.  But perhaps I missed
the purpose for returning an error code for loops.


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


Jason.

Received on Sunday, 1 August 1999 17:05:21 UTC