- From: James J. Hunt <jjh@allerton.de>
- Date: Tue, 06 Feb 2001 03:21:51 +0000
- To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
- CC: ietf-dav-versioning@w3.org
Dear Geoff, "Geoffrey M. Clemm" wrote: > 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? Section 1.6, "Response Bodies for 403 and 409 Status Responses," states the following: "In a 207 Multi-Status response, this element would appear in the appropriate DAV:response-description element" DAV:response-description is defined as <!ELEMENT responsedescription (#PCDATA)> which is not a tag. The solution is replace all occurrences of responsedescription with (responsedescription | error) where error is defined as <!ELEMENT error (user-defined-error | put-under-version-control-error | already-under-version-control-error | cannot-modify-version-controlled-content-error | cannot-modify-version-error | cannot-modify-version-controlled-property-error | cannot-modify-protected-property-error | cannot-modify-unsupported-property-error | auto-version-when-unlocked-error | cannot-delete-root-version-error | cannot-delete-referenced-version-error | no-version-delete-error | update-predecessor-set-error | initialize-precursor-error | auto-checkout-when-locked-error | cannot-rename-resource-error | preserve-history-error | must-be-checked-in-error | is-checked-out-error | initialize-predecessor-set-error | must-be-checked-out-error | version-history-is-tree-error | create-version-error | initialize-version-content-and-properties-error | checked-in-error | keep-checked-out-error | must-be-checked-out-version-controlled-resource-error | cancel-checked-out-error | restore-content-and-dead-properties-error | must-be-checked-in-version-controlled-resource-error | must-select-version-in-same-history-error | update-content-and-dead-properties-error | update-checked-in-property-error | must-be-version-history-error | delete-version-set-error | cannot-copy-history-error | new-version-history-error | add-to-history-error | create-working-resource-error | create-working-resource-from-checked-in-version-error | delete-working-resource-error | resource-must-be-null-error | workspace-location-ok-error | initialize-workspace-error | delete-workspace-members-error | workspace-member-moved-error | workspace-moved-error | cannot-add-to-existing-history-error | must-be-version-error | one-version-controlled-resource-per-history-per-workspace-error | new-version-controlled-resource-error | cannot-merge-checked-out-resource-error | checkout-not-allowed-error | ancestor-version-error | descendant-version-error | checked-out-for-merge-error | update-merge-set-error | report-ignored-set-error | report-properties-error | delete-version-reference-error | merge-must-be-complete-error | must-not-be-checked-out-error | must-be-new-label-error | label-must-exist-error | add-label-error | remove-label-error | must-not-have-label-and-apply-to-version-error | depth-update-error | version-controlled-configuration-must-be-empty-error | must-be-baseline-error | must-have-no-version-controlled-members-error | one-baseline-controlled-collection-per-history-per-workspace-error | create-version-controlled-configuration-error | reference-version-controlled-configuration-error | select-existing-baseline-error | create-empty-baseline-error | baselines-from-same-history-error | no-checked-out-baseline-controlled-collection-members-error | create-baseline-collection-error | auto-baseline-error | baseline-controlled-members-must-be-checked-in-error | set-baseline-controlled-collection-members-error | merge-baseline-error | activity-location-ok-error | initialize-activity-error | must-be-activity-error | delete-activity-reference-error | update-checked-out-reference-error | update-activity-reference-error | update-workspace-reference-error | one-checkout-per-activity-per-history-error | linear-activity-error | initialize-activity-set-error | initialize-unreserved-error | atomic-activity-checkin-error | checkin-activity-error | cannot-modify-checked-in-parent-error | cannot-modify-destination-checked-in-parent-error | initialize-version-history-bindings-error | initialize-version-controlled-bindings-error | version-control-working-collection-members-error | update-version-controlled-collection-members-error | checkout-of-version-with-descendant-is-forbidden-error | checkout-of-version-with-descendant-is-discouraged-error | checkout-of-checked-out-version-is-forbidden-error | checkout-of-checked-out-version-is-discouraged-error | checkin-fork-forbidden-error | checkin-fork-discouraged-error | cannot-delete-default-variant-error | delete-variant-reference-error | cannot-rename-variant-error | variant-control-error | create-new-variant-error | delete-variant-predecessor-error | must-select-variant-error | update-default-variant-error | update-variant-controlled-resource-error)> <!-- May be extended here --> <!ELEMENT user-defined-error ANY> <!--- new!! --> > > > 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. > One could do both! One could also weaken the requirement so that it could be expressed with * and write something like "tag foo should occur at most once; additional occurrences should be ignored." Note that with boolean tags, there is no difference between one occurrence and n occurrences: on is on. > > 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 (:-). A pure text version of the spec would help. MS Word leaves too much junk in the HTML. This only makes sense if we can agree that a DTD for this protocol should be included in the document and the DTD is definitive (aside from the at most once issue) . > > > 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. This is an unfortunate, but not over burdening restriction. > > > 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. See previous message, but testing during implementation is another example of where a DTD can be useful. There may be good reasons why one would not wish to do verification in a production system, but a DTD is a formal specification that one can verify against. It will not catch all errors, but it can catch many stupid, annoying ones. > > > 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. Everywhere that ANY is used. For instance, if I want to know what parameters checkout can take, I have to examine the entire document. A good DTD at the end would help a lot. > > > 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. It makes the structure obvious, instead of relying on the fact that prop is defined as ANY. I can make the structure clear with a relatively concise DTD. I will send a new full example using tags for properties along with the corresponding DTD. > > Cheers, > Geoff Sincerely, James P.S. I took the liberty of adding -error to the end of all error tags. This helps avoid tag conflicts and makes the tag more obviously an error message. P.P.S. As a boolean tag in checkout unreserved is okay, but as an attribute that can be true or false, I find reserved to be a better name. Reserved = true makes more immediate sense than unreserved = true. P.P.P.S. It would be nice to have a boolean tag for this, instead of PCDATA. How about <!ELEMENT boolean EMPTY> <!ATTLIST value (true | false) #REQUIRED>
Received on Monday, 5 February 2001 23:58:20 UTC