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

From: "Julian Reschke" <[email-masked]>
Date: Wed, 6 Aug 2003 15:03:50 +0200

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

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 6 Aug 2003 09:45:28 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Wednesday, August 06, 2003 6:04 AM
> To: [email-masked]
> 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
> 
> --

---

From: Frank Lowney <[email-masked]>
Date: Sun, 10 Aug 2003 10:26:32 -0400

Please let me know if I am posting to the wrong list and suggest 
better venues if I'm off target.

Posting:

The Goal:
This may be premature on our part but we are trying to take advantage 
of the WebDAV standard to accomplish two major goals across a variety 
of web-based facilities:

1) Eliminate or significantly reduce reliance upon FTP so as to obtain:
    a) higher levels of ease-of-use on behalf of content experts who 
are not technophiles
    b) higher levels of security (FTP sends PWs in the clear, SFTP is 
complex & finicky, etc.)
    c) divert the current high demand for proprietary solutions such 
as MS FrontPage server extensions.

2) Simplify the training of content experts publishing via the web by:
    a) Training for fewer applications (no instruction in a number of FTP apps)
    b) Train for apps that offer greater expressive freedom (Adobe 
GoLive and Macromedia Dreamweaver instead of MS FrontPage, AOL Press, 
Netscape Composer, etc.) that also use WebDAV effectively.

The Problem:
WebDAV simply doesn't seem to work consistently and well over the 
range of server and client environments that we must work with.  The 
following sketches out those environments:

Server Environments:
NOTE: All claim to support the WebDAV standard but end user 
experience tends to contradict those claims.

WebCT Vista 2.x (see 
http://www.webct.com/products/viewpage?name=products_vista).  As I 
understand it, this Courseware Management System (CMS) is based upon 
the BEA WebLogic webserver and an Oracle 9i database.

Apache webserver (as implemented in the MacOS X Server suite, see: 
http://www.apple.com/macosx/server/).

WebSTAR V webserver (as implemented in the 4D WebSTAR Server Suite, 
see: http://www.4d.com/products/webstar.html)

Client Environments:
The overall issue here is that consistency and reliability is absent 
from all these environments.  Consequently. our training efforts have 
not been as successful as we would like them to be.

Windows 98, 2000, and XP
NOTE: There are a variety of strategies that trainers must be 
prepared to present to end users: Internet Explorer & Web Folders, My 
Network Places, etc.  None of these work completely as advertised 
across all environments.

MacOS X
Native OS support **appears** to be both robust and easy-to-use in 
the case of Apple's ostensibly WebDAV-based dotMac service but 
clients have difficulty in other WebDAV environments.

MacOS Classic (8.6 to 9.2)
Requires the use of an app such as Goliath.  We have few clients 
using this OS/app combination so pilot error may be a 
disproportionately great factor but the experience reported here is 
spotty as in the case of all other client environments.

Discussion:

We are perhaps naive in expecting the WebDAV standard to be so 
complete and internally consistent as well as so thoroughly and 
faithfully implemented in both server and client environments that 
training could be simple, straightforward and w/o a raft of "ifs," 
"ands" or "buts."  True?

Is there an ongoing discussion somewhere for folks like us who are 
trying to implement WebDAV into  our work flow?

-- 
=====================================================================
Dr. Frank Lowney  [email-masked]
     Director, Electronic Instructional Services, a unit of the
     Office of Information and Instructional Technology,
     Professional Pages: http://www.gcsu.edu/oiit/eis/
     Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
=====================================================================
We don't make instruction effective, we make effective instruction 
more accessible.

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 10 Aug 2003 20:39:23 +0200

First of all, you are absolutely on the right mailing list. There's also a
special WebDAV interop list, but that one is mainly used to organize and
exchange interop test results.

You didn't mention exactly *what* problems you see. In general, there are
quite a few vendors that advertise WebDAV compliance, but test their servers
only with the Microsoft webfolder client, therefore having lots of problems
with other clients. On the other hand, you may also see client issues.

A few things you can do:

- If you suspect a server compliance issue, as a first step run the Litmus
test suite against it [1].

- If you suspect a Microsoft webfolder client issue, check the list of known
versions and their issues [2].

- If you suspect a MacOSX client issue, report it here. Apple programmers
are (hopefully they still are!) monitoring this list and are very
responsive.

- If you think you have found an Apache/moddav issue, you probably should
report it to the dav-dev mailing list [3].

- Otherwise, just describe your specific problem here and we'll try to help.

Hope this helps,

Julian

[1] <http://www.webdav.org/neon/litmus/>
[2] <http://greenbytes.de/tech/webdav/webfolder-client-list.html>
[3] <http://dav.lyra.org/mailman/listinfo/dav-dev>

> [mailto:[email-masked]]On Behalf Of Frank Lowney
> Sent: Sunday, August 10, 2003 4:27 PM
> To: [email-masked]
> Subject: WebDAV Standards, browser & server compliance
>
>
>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 11 Aug 2003 10:42:49 -0700

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

> [mailto:[email-masked]] On Behalf Of Lisa Dusseault
> Sent: Wednesday, August 06, 2003 9:45 AM
> To: 'Julian Reschke'; [email-masked]
> 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
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Mon, 11 Aug 2003 13:48:10 -0400

I support the former as well (order is irrelevant unless explicitly
stated otherwise).

Cheers,
Geoff

---

From: Elias Sinderson <[email-masked]>
Date: Mon, 11 Aug 2003 10:57:07 -0700

+1, being less strict unless otherwise noted is the best approach.

Elias

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 11 Aug 2003 20:34:03 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, August 11, 2003 7:43 PM
> To: 'Lisa Dusseault'; 'Julian Reschke'; [email-masked]
> Subject: RE: another thought on "is element order significant" vs DTDs
> in WebDAV
>
>
>

Agreed. Order may be significant for *execution* (and I think the spec
already clearly says where this is the case). I was considering *validity*.

> PROPFIND response body is an exception?

The former.

> I favour the first - the general rule being that order is irrelevant
unless

Correct. A related issue is when unknown elements are to be ignored
(generally yes, but for instance not within PROPFIND/prop).

Julian