Re: DAV Versioning DTD.

James and Juergen:

Thanks for all your hard work in the DTD area!
It looks below like you have uncovered some problems or 
ambiguities in the protocol.  Even if we do not end up
using validating DTD's as our syntactic definition
mechanism, any technique that uncovers a problem is
of great value.

   From: "James J. Hunt" <jjh@allerton.de>

   The current definition of how errors are returned in DAV versioning is
   incompatible with WebDAV.  I have made a change that should be help
   there.

This should be fixed.  Could you describe how error returns in DAV
versioning is incompatible with WebDAV?

   The "at most one of .... in any order "is defined with an
   arbitrary order here.  I will fix that as well, though it will not
   pretty be pretty.   Please let me know if I have forgotten anything.

Well, that's one of the concerns with using DTD's.  If something that
can easily and clearly be expressed in English (i.e. "at most one
of ... in any order") requires a complex DTD, then the constraint
might be better expressed in English.

   The DTD and two examples, which validate against the DTD using Sun's
   latest XML parser, are included.   Can you easily send me the all
   examples from the current draft or at least the draft as text?

All I've currently got (i.e. the latest .doc version and a generated html
version) are now up on the web site).  Anything you can do to clean
up the examples would be great!  I've read them so many times that
my eyes just blur over when I try to read them again (:-).

   The tags add, set, and remove as used in labels, must be renamed
   because set and remove are already defined differently for
   propertyupdate.

This is a key question.  We currently are using XML in argument lists.
Requiring that a given element type have exactly one global definition
is like saying that each function must have formal parameter names
that are different from every other formal parameter name of any other
defined function.  This is clearly a major constraint, and disallowing
both PROPPATCH and LABEL to use DAV:set is a good example of this.

Now we could change to saying that there is a generic DAV:arg
element type, and have an attribute say what kind of arg it is,
but that would be inconsistent with the conventions of 2518.

So unfortunately, I believe you are going to have to provide some
compelling arguments for why XML validation matters in a WebDAV
context (other than making it easier to proof check some of the
surface syntax of the examples :-).  Minimally, you will probably need
to rebut the argument in my preceding message that there is no
compelling argument for XML validation by a WebDAV message processor.
As a reminder, this argument says that "if XML validation succeeds, it
has no effect on processing of a message, and if XML validation fails,
but the message can be understood by the message processor, a
forgiving message processor will go ahead and process the message
anyway."  So given the cost of passing a DTD along with a message, or
the cost to a server of accessing any remote DTD that it doesn't have
cached locally, I see no evidence that many server writers will bother
with validation, or care about the results even if they did validate.

   I still believe that a complete DTD is helpful for people who have not
   had a chance to sit in on all the DAV versioning discussions.  I find
   the document to be too dependent on examples.  A DTD that is consistent
   with the examples would help.

Perhaps if you indicated the places where the XML value syntax in the
versioning protocol is ambiguous or unclear, we could then decide if a
DTD is the appropriate mechanism to clear it up.

   P.S. An example of  our new proposal for expand-property with properties
   as tags instead of attributes will be as follows:

   <?xml version=3D"1.0" encoding=3D"utf-8" ?>
   <!DOCTYPE DAV:webdav-1.0 SYSTEM
   "http://www.webdav.org/dtd/deltav-0.12.1.1.dtd" !>
   <expand-property xmlns=3D"DAV:">
     <prop-apply>
       <version-history/>
       <prop-apply>
	 <version-set/>
	 <prop>
	   <creator-displayname/>
	   <activity-set/>
	 </prop>
       </prop-apply>
     </prop-apply>
   </expand-property>

This is certainly simpler than the attribute form, but it
is still more complicated than what we have now.

Cheers,
Geoff

Received on Monday, 5 February 2001 16:22:10 UTC