RE: bind draft issues

Brian:

These are the kinds of issues that led us to remove any discussion
of PROPFIND from the bindings draft.  My conclusion is that our best
approach is to leave it up to 2518bis to define generically
how property values behave in the presence of multiple URL mappings
to the same resource (since that is base WebDAV functionality, not
something introduced by the binding spec), and the binding draft
will focus on the semantics it introduces (such as the DAV:resource-id
property, whose behavior in the presence of multiple URL mappings is
defined).

The binding spec can then focus on the semantics that it is introducing,
i.e. client creation of multiple URL mappings, the resource-id property,
and atomic MOVE/DELETE via REBIND/UNBIND.

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Friday, March 07, 2003 5:26 AM
To: Stefan Eissing; Julian Reschke
Cc: Clemm, Geoff; WebDAV
Subject: RE: bind draft issues


> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: Friday, March 07, 2003 11:00 AM
> To: Julian Reschke
> Cc: Clemm, Geoff; WebDAV
> Subject: Re: bind draft issues
>
>
>
> Am Freitag, 07.03.03, um 10:45 Uhr (Europe/Berlin) schrieb Julian
> Reschke:
>
> >> From: w3c-dist-auth-request@w3.org
> >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> >> Sent: Friday, March 07, 2003 10:34 AM
> >> To: Julian Reschke
> >> Cc: Clemm, Geoff; WebDAV
> >> Subject: Re: bind draft issues
> >>
> >> ...
> >>
> >>>> Hmm, I think I know what you mean, however there are cases
> >>>> where you might want this to break:
> >>>>
> >>>> 1) variants. /news/english/ and /news/german/ might be the same
> >>>>    resource with different content based on the "access" URL. All
> >>>>    get* properties will probably vary. (They can already vary on
> >>>>    a resource with a single binding)
> >>>
> >>> That would mean that entities may vary based on the request URI. Is
> >>> this the
> >>> case?
> >>
> >> I thought that's what I wrote.
> >
> > OK, I rephrase it: that would mean that a resource is *allowed* to vary
> > based on the request URL. I don't think we all agree on that.
>
> Uhh, it can vary based on "Accept-Language" request header. Why should
> it not vary on the request URI of the GET?

If we allow the entity to vary based on the URL, what exactly can I rely to
be constant? What's the point of having the concept of "same" resource then?

> [...]
> >>>> What exactly is it, you want to prevent to happen?
> >>>
> >>> People falling into the trap of believing in "URL properties", I
> >>> guess.
> >>
> >> Probably a good guess of Geoff's intentions. Why not give a guess
> >> what an "URL property" exactly is? That would be most welcome.
> >
> > Our (Geoff's any my) understanding is that there *are* no URL
> > properties. A
> > URL property would be something that varies with the request URL
> > (under the
> > relaxed "sameness" definition stated above).
>
> So: properties can vary based on HTTP request headers, but not based on
> the HTTP request URI? Or do you think they should not vary based on

Yes.

> HTTP request headers either? Or that only the get* properties are  allowed
> to do that?

Properties right now do not distinguish between resource properties and
entity properties. That's a design bug inherited from the HTTP header
mechanism. I don't think there's an easy way to fix this.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 7 March 2003 10:22:13 UTC