W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

RE: WebDAV DTD

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Tue, 12 Oct 1999 13:13:41 -0700
To: w3c-dist-auth <w3c-dist-auth@w3.org>
Message-ID: <NDBBIKLAGLCOPGKGADOJOEIACGAA.ejw@ics.uci.edu>


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

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.

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

- Jim
Received on Tuesday, 12 October 1999 16:14:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:52 GMT