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

Actually, for maximizing interoperability, I'll modify my
suggestion to state:

A server SHOULD adhere to the ordering implied by the DTD, but
a client SHOULD accept an arbitrary ordering.

This is just what I would do when implementing a client and a server,
but I don't have a strong opinion about what the spec should say in
this regard.

Cheers,
Geoff 

Geoff wrote on 06/23/2003 07:58:16 AM:

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