Subject: Re: WebDAV DTD

From: [email-masked] (Tim Ellison OTT)
Date: Tue, 12 Oct 1999 16:55:55 -0400

>The benefit is that, if the client sees the status first, and knows
>the operation failed, then it can avoid buffering the contents of
>the prop element.  With an existing server, the only problem
>would be that it would have to buffer all the time.

Exactly -- I can see it now, some bright spark chooses to store a hunk of 
video in a property ... or a long live property ...

>Uh...but now I'm wondering whether this actually makes sense.
>Is there any case where the operation failed but you get a prop
>with an actual value in it?

The only cases that seem to make sense to me are those where the server 
manages to retrieve partial content before the error occurs.  Presumably 
these would result in error code (500 Internal Server Error).

Tim
 ----------
>From: John Stracke
>To: w3c-dist-auth
>Subject: Re: WebDAV DTD
>Date: Tuesday, October 12, 1999 4:32PM
>
><<File Attachment: HEADER.TXT>>
>Jim Whitehead wrote:
>
>> > One rule in the DTD states:
>> >     <!ELEMENT propstat (prop, status, responsedescription?) >
>> >
>> > I suggest that this is modified to read
>> >     <!ELEMENT propstat (status, responsedescription?, prop) >
>> >
>> > so that streaming clients can retrieve the status of a property
>> > before they retireve the property itself , and thereby know whether the
>> data
>> > is valid or not.  In the current rule, such a client is required to 
read
>> the prop data
>> > in its entirety, possibly to discover that the data is invalid only 
after
>> > the fact.
>>
>> That said, I don't find this to be a particularly compelling argument. 
 In
>> general you'll need to parse the entire propstat block anyway just so you
>> can find its end.  And, clients will need to be able to accept either
>> ordering, since there are existing servers that send the data as prop,
>> status, responsedescription. So, I'm not sure what benefit this change 
gains
>> you.
>
>The benefit is that, if the client sees the status first, and knows the
>operation failed, then it can avoid buffering the contents of the prop
>element.  With an existing server, the only problem would be that it would
>have
>to buffer all the time.
>
>Uh...but now I'm wondering whether this actually makes sense.  Is there any
>case where the operation failed but you get a prop with an actual value in 
it?
>
>--
>/==============================================================\
>|John Stracke    | http://www.ecal.com |My opinions are my own.|
>|Chief Scientist |=============================================|
>|eCal Corp.      |But this one goes to 11x.                    |
>[email-masked]|                                             |
>\==============================================================/
>
>
>
>

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 12 Oct 1999 14:58:02 -0700

Um, wait a minute, this still doesn't make sense.  If a server uses your
recommended oredering for the propstat XML element and sends the status
first, then starts streaming data out of its property store, and then
detects an error ... there's no way to put that error into the response,
since you've already sent the status, right?  Assuming the server isn't
streaming the data out doesn't work either -- if the server reads the entire
property out before marshalling the response, then it can detect ahead of
time that there was an error, and just not send any information at all for
the property, thereby avoiding the case that motivates the ordering change
in propstat.

> >> >     <!ELEMENT propstat (status, responsedescription?, prop) >

- Jim