Subject: RE: WebDAV DTD

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

Is there any support within the group for this change to the DTD?

Without it I fail to see how clients can receive large properties without 
inhaling the entire contents.

Tim

 -----Original Message-----
From: Tim Ellison OTT [mailto:[email-masked]]
Sent: Monday, October 04, 1999 12:48 PM
To: w3c-dist-auth
Subject: [Moderator Action] WebDAV DTD

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.

Comments?

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 12 Oct 1999 13:13:41 -0700

> inhaling the entire contents.

A couple of responses.  First, it was never our intent for the ordering of
XML elements given in the DAV DTD to be normative, and this was one of the
reasons we specified that XML in DAV is only well formed, and is not
required to meet the more stringent validity requirements. However, we
should be more explicit about this intent in the spec., since someone
reading the DTD would certainly get the impression that the ordering there
is normative.  So, answer #1 is that you already have permission to make the
change you suggested in your code.

> 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

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.

- Jim

---

From: John Stracke <[email-masked]>
Date: Tue, 12 Oct 1999 16:29:36 -0400

> status, responsedescription. So, I'm not sure what benefit this change gains

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]|                                             |
\==============================================================/