Subject: Anomaly in the DAV:prop element usage

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 6 Jan 2000 18:08:50 -0500

In rfc2518, the example of propfind in 8.1.1 issues a PROPFIND
request with a DAV:prop element of the form:

     <D:prop xmlns:R="http://www.foo.bar/boxschema/">
          <R:bigbox/>
          <R:author/>
          <R:DingALing/>
          <R:Random/>
     </D:prop>

It is very likely that this violates at least some of the element
definitions for R:bigbox, R:author, R:DingALing, and R:Random.

I have gone to some trouble to avoid this kind of element definition
violation in the versioning spec, but since it didn't bother the
authors of 2518, should I not let it bother me?  As was pointed out
in an earlier thread, there are other reasons why WebDAV XML will be
rejected by validating parsers ...

Cheers,
Geoff

---

From: "Kaelin Colclasure" <[email-masked]>
Date: Thu, 6 Jan 2000 15:56:26 -0800

----- Original Message ----- 
From: Geoffrey M. Clemm <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 06, 2000 3:08 PM
Subject: Anomaly in the DAV:prop element usage

> rejected by validating parsers ...

The use of a validating parser makes little sense in the context of
WebDAV properties -- because it is intended to expose a storage mechnism
for arbitrary element definitions (in the form of property values),
which themselves may or may not have a defined DTD or schema somewhere.

Is the versioning specification defining a similar mechanism whereby
arbitrarily defined elements would need to be incorporated? If not,
then indeed you should be sensitive to the requirements of validation.
But if so, the same argument stated above for property values applies.

-- Kaelin

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 6 Jan 2000 16:55:49 -0800

This is an interesting issue--how do specify some set of XML elements that
you want out of a document not available to you.  This is basically the XML
equivalent of a SELECT list in SQL.

I raised this issue in the database context with the W3C people a few months
ago, to raise the issue of a simplified form of XPath for this purpose.  I
proposed basically using a list of XPath identifiers, omitting elements in
the predicate that reference the value of any node.

I'm copying this to some relevant XML & XPath people to highlight WebDAV
PROPFIND requests as another application for this usage in addition to
database data retrieval.  It's kind of disturbing to me to see invalid XML
used for this--I'd prefer a comma separated list of XPath specifications,
omitting predicates, like:

<D:prop xmlns:R="http://www.foo.bar/boxschema/">
 R:bigbox, R:author, D:supportedlock/lockentry/lockscope
</D:prop>

I think this will avoid confusion, since a list of XML element names
shouldn't appear as empty elements.

--Eric

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 6 Jan 2000 22:42:08 -0500

From: "Eric Sedlar" <[email-masked]>

Yes!  (It is comforting to know that at least one other person out
there worries about this kind of thing :-).  In the versioning
context, it comes up in the REPORT method.  An important report is a
DAV:available-reports report (analagous to an OPTIONS call, but
returning the reports available, rather than the methods applicable).

My concern with this approach is that the parser won't know that this
identifier is an element name, so the application would have to do the
processing itself (e.g. keeping track of the namespaces defined in that
context, and replacing the namespace prefix with the appropriate URL).
This is feasible, but does require the application to internally contain
parsing knowledge.

The alternative, using empty elements that violate the element definition
avoids this problem, at the cost of being invalid XML.

For the DAV:available-report REPORT, I have avoided the problem by
defining DAV:xxx-report to be the element returned in the
DAV:available-reports response, DAV:xxx-report-request be the element
in the request body for that kind of report, and
DAV:xxx-report-response be the element in the response body for that
kind of report.

But for the (recently added) DAV:property-report REPORT (which does
a PROPFIND on the resources referenced by properties that are a
list of href's), I can't avoid the "XML-select" problem.

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 6 Jan 2000 22:53:44 -0500

From: "Kaelin Colclasure" <[email-masked]>

Yes, that makes sense (although you do have to at least specify the
namespace of those elements, even if you don't have the DTD's).  But
in those cases where you do have the DTD's available (such as for the
DAV:xxx properties), it does provide some cognitive dissonance to
see an element like <DAV:creationdate/> in a PROPFIND request,
when the DTD for creationdate is:
   <!ELEMENT creationdate (#PCDATA) >

Cheers,
Geoff

---

From: Jim Davis <[email-masked]>
Date: Fri, 07 Jan 2000 09:11:10 +0100

>see an element like <DAV:creationdate/> in a PROPFIND request,

I agree that it is dissonant.   But there may be no better choice.

Let me make a suggestion - let he who thinks WebDAv should validate create
a DTD that will work.  The constraint is that it has to work even if there
is no DTD for some properties, and whatever mechanism you use should also
not have the bad network effect of needing to fetch the DTD with each
attempt to validate.  otherwise performance would be bad.  I am no XML
expert, so I can't tell whether this is easy or even possible.

I would certainly be willing to see changes to the DTD that would *allow*
webDAV XMl to be validating, if I didn't have to give up on expressivity
(ability to use properties without a DTD)

All things being equal, this would be better for DASL as well.  As one of
the authors I can say that I did spend some time trying to write a DTD for
DASL, mostly because I wanted to be able to check for dumb mistakes that *I
made.

Note also that RFC 2518 says that WebDAV's xml is not valid.  (but only in
passing in 17.7)  i think, given the amount of discussion that this has
brought up over history, it needs a passage in the WebDAV book of Why, if
not in the next Specification.

---

From: Jim Whitehead <[email-masked]>
Date: Thu, 13 Jan 2000 17:49:47 -0800

Geoff Clemm writes:

> But

Actually, in this specific case the XML is valid.  The construction
<element/> is defined to be the same as <element></element> (an element with
no contents).  Since an empty element is consistent with the *DTD* for
creationdate, <creationdate/> is valid.  But, your point still holds for
properties like lockdiscovery, which have a list of subelements as part of
their DTD specification, so my objection is to your example, not to your
general point.  That said, I still think using a list of empty elements is
fine within prop.

- Jim