RE: Reconsidering DTDs and validity (was RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt)

I'd suggest that we start with a generic statement that DTD implied
ordering is to be ignored, but that the definition of a particular
element can explicitly declare that ordering matters. 

WRT this particular case, I don't think that the amount of memory/time
required on the client to read in the propstat before knowing what
URL it is for is significant enough to matter (but like Julian,
I don't care strongly either way, so I wouldn't object if the consensus
is to make ordering matter in this particular element).

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 06/22/2003 10:22:19 AM:

> 
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Joe Orton
> > Sent: Sunday, June 22, 2003 1:08 PM
> > To: w3c-dist-auth@w3.org
> > Subject: Re: Reconsidering DTDs and validity (was RE: I-D
> > ACTION:draft-ietf-webdav-rfc2518bis-03.txt)
> >
> >
> >
> > I think it's important to retain some of the ordering constraints 
given
> > by the DTD fragments in 2518 - specifically it is useful that a client
> 
> I really don't care much about the issue. However, we really really need 
to
> decide this, and then stay consistent. The current situation obviously 
is
> problematic.
> 
> *If* we decide that ordering *is* relevant, we should clarify that both
> servers and clients must reject messages that do not comply. I don't 
want to
> end up in a situation where some clients work with non-compliant 
servers,
> while others don't.
> 
> However, my feeling is that *currently* almost everybody ignores the
> ordering, and that server behaviour is *not* consistent. Thus from a
> standards progress point of view, it would make sense for RFC2518bis 
just to
> state that the ordering is irrelevant.
> 
> > can assume that in the response element, a propstat MUST be preceded 
by
> > an href.
> >
> > Since a propstat cannot be interpreted without knowing which URI it
> > applies to, if this constraint is missing, the client is required to 
be
> > able to batch propstats in memory until the href arrives.  With this
> > constaint, propstats can always be processed on the fly.
> 
> Stream processing of response bodies is a very interesting problem. 
However,
> I think even if you can rely on ordering, it is still hard. For 
instance,
> how do you process:
> 
>    <D:multistatus xmlns:D="DAV:">
>      <D:response>
>           <D:href>http://www.foo.bar/file</D:href>
>           <D:propstat>
>                <D:prop xmlns:R="http://www.foo.bar/boxschema/">
>                     <R:bigbox>
>                          <R:BoxType>Box type A</R:BoxType>
>                     </R:bigbox>
>                     <R:author>
>                          <R:Name>J.J. Johnson</R:Name>
>                     </R:author>
>                </D:prop>
>                <D:status>HTTP/1.1 200 OK</D:status>
>           </D:propstat>
>           <D:propstat>
>                <D:prop><R:DingALing/><R:Random/></D:prop>
>                <D:status>HTTP/1.1 403 Forbidden</D:status>
>                <D:responsedescription> The user does not have access to
>    the DingALing property.
>                </D:responsedescription>
>           </D:propstat>
>      </D:response>
>     This is malformed: &
>    </D:multistatus>
> 
> A compliant client must reject this reponse, because the body is 
malformed.
> 
> BTW: you will need to batch the propstat element until you've reached 
the
> DAV:status element (confirming it's a "200") anyway. I don't see a big
> difference to waiting for the closing response tag.
> 
> 
> Julian
> 
> 
> 
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>