Re: DAV Versioning DTD.

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