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


From: John Stracke <francis@ecal.com>
Date: Tue, 12 Oct 1999 16:29:36 -0400
Message-ID: <38039A30.7BB3DD9F@ecal.com>
To: w3c-dist-auth <w3c-dist-auth@w3.org>
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.                    |
|francis@ecal.com|                                             |
Received on Tuesday, 12 October 1999 16:30:09 UTC

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