RE: another thought on "is element order significant" vs DTDs in WebDAV

I just noticed that the specification for PROPPATCH says that property
changes MUST be applied in order.  So clearly there are already some cases
in WebDAV in which XML order of elements is significant.  

I still think it's a good idea to say at a minimum that the order of
resources and properties in a PROPFIND response is irrelevant.  So should we
say that in general order is irrelevant but the PROPPATCH request body is an
exception?  Or should we say that in general order is important but the
PROPFIND response body is an exception?

I favour the first - the general rule being that order is irrelevant unless
specified as relevant. 

Lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Lisa Dusseault
> Sent: Wednesday, August 06, 2003 9:45 AM
> To: 'Julian Reschke'; w3c-dist-auth@w3.org
> Subject: RE: another thought on "is element order 
> significant" vs DTDs in WebDAV
> 
> 
> 
> I agree.  I'll add a further reason, which is that it's more 
> important for servers, which handle 1000s of clients, to be 
> able to stream data out in the order most quickly obtainable, 
> to maximize server performance.
> 
> Lisa
> 
> > -----Original Message-----
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> > Sent: Wednesday, August 06, 2003 6:04 AM
> > To: w3c-dist-auth@w3.org
> > Subject: another thought on "is element order significant" vs 
> > DTDs in WebDAV
> > 
> > 
> > 
> > Hi,
> > 
> > here are a few reasons why I think WebDAV should say that
> > element ordering is irrelevant:
> > 
> > 1) There are already existing well-deployed servers (in this
> > case IIS) that get the ordering wrong (here: propstat 
> > content), thus clients can't rely on ordering anyway for all 
> > practical purposes,
> > 
> > 2) Requiring a specific ordering will make protocol
> > extensions extremely hard. For instance, take two independant 
> > extensions "A" and "B" that extend RFC2518 and add new 
> > elements to the same container element. If at a later point a 
> > new protocol revision  tries to integrate both extensions, it 
> > will be hard to come up with a simple DTD that consolidates 
> > both changes.
> > 
> > Julian
> > 
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> > 
> > 
> 
> 
> 
>

Received on Monday, 11 August 2003 13:42:06 UTC