W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

Re: bind draft issues

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 7 Mar 2003 10:33:41 +0100
Cc: "Clemm, Geoff" <gclemm@rational.com>, "WebDAV" <w3c-dist-auth@w3.org>
To: "Julian Reschke" <julian.reschke@gmx.de>
Message-Id: <E2594BFB-507F-11D7-B755-00039384827E@greenbytes.de>

Am Freitag, 07.03.03, um 10:06 Uhr (Europe/Berlin) schrieb Julian 

>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
>> Sent: Friday, March 07, 2003 9:53 AM
>> To: Clemm, Geoff
>> Cc: WebDAV
>> Subject: Re: bind draft issues
>> Am Freitag, 07.03.03, um 00:50 Uhr (Europe/Berlin) schrieb Clemm, 
>> Geoff:
>>> How about the following statement about PROPFIND:
>>> "If two URLs are mapped to the same resource, the property
>>>  values returned by PROPFIND on those two URLs MUST be
>>>  identical."
>> 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.

>> 2) live props with URI References can report different relative uri
>>    references. They are semantically equivalent, but the string value
>>    of such a property will differ.
> For instance?

for PROPFIND result on /a/b/c/d/vcr
for PROPFIND result on /a/b/c/vcr
with both "vcr" being bindings to the same resource.

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

Received on Friday, 7 March 2003 04:34:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC