W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Definition of DAV:error and it's use in multistatus...

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Wed, 6 Feb 2002 18:27:59 +0100
To: "Peter Raymond" <Peter.Raymond@merant.com>, "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCOEJMDPAA.julian.reschke@greenbytes.de>
RE: Definition of DAV:error and it's use in multistatus...Peter,

the DTD isn't normative. It can't be. I think this was discussed to great
length on the ACL mailing list in December, but for some odd reason, the
archive for this particular month is missing...

  -----Original Message-----
  From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Peter Raymond
  Sent: Wednesday, February 06, 2002 6:14 PM
  To: Clemm, Geoff; ietf-dav-versioning@w3.org
  Subject: RE: Definition of DAV:error and it's use in multistatus...


  Hi,

  The DTD for DAV:responsedescription is:

  <!ELEMENT responsedescription (#PCDATA) >

  If you want to put the DAV:error element beneath DAV:responsedescription
  then the DTD should be modified to something like:

  <!ELEMENT responsedescription (#PCDATA | error)* >

  This would allow a mix of character data and the DAV:error element.
  As the DTD stands today it only allows character data.

  Regards,
  --
  Peter Raymond - MERANT
  Principal Architect (PVCS)
  Tel: +44 (0)1727 813362
  Fax: +44 (0)1727 869804
  mailto:Peter.Raymond@merant.com
  WWW: http://www.merant.com




  -----Original Message-----
  From: Clemm, Geoff [mailto:gclemm@rational.com]
  Sent: 06 February 2002 13:06
  To: ietf-dav-versioning@w3.org
  Subject: RE: Definition of DAV:error and it's use in multistatus...



  The rationale
  for putting it in the DAV:responsedescription node
  is that the DAV:responsedescription corresponds to
  the "body" of a non-multi-status response, and
  that is where the DAV:error node appears in a
  non-multi-status response.

  This does not violate the DTD for DAV:responsedescription,
  because a client is required to ignore any node that it
  doesn't understand, so it doesn't matter where you put it.

  Cheers,
  Geoff

  -----Original Message-----
  From: Peter Raymond [mailto:Peter.Raymond@merant.com]
  Sent: Tuesday, February 05, 2002 4:13 PM
  To: ietf-dav-versioning@w3.org
  Subject: Definition of DAV:error and it's use in multistatus...



  Hi,
  Section 1.6 of the DeltaV specification defines how the pre and post
  condition XML
  elements should be returned.  It says:
  "the appropriate XML element MUST be returned as the child of a top-level
  DAV:error
  element in the response body, unless otherwise negotiated by the request.
  In a 207
  Multi-Status response, the DAV:error element would appear in the
appropriate

  DAV:responsedescription element."
  This is the only definiton of DAV:error, there is no DTD for this element
as
  far
  as I can tell and no examples of it's use within a multistatus response.
  It would seem to violate the DTD defined in RFC2518 for
  DAV:responsedescription.
  Am I correct in thinking that the syntax should be:
  <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
      <D:response>
        <D:href>http://www.merant.com/webdav/ws1/test.html</D:href>
        <D:status>HTTP/1.1 409 CONFLICT</D:status>
        <D:responsedescription>
          <D:error>
            <D:label-must-exist/>
          </D:error>
          Label specified does not exist
        </D:responsedescription>
      </D:response>
    </D:multistatus>
  The human readable text describing the error and the DAV:error element are
  children
  of the DAV:responsedescription element.  This seems very odd.  Why not
have
  the
  DAV:error element as a child of the DAV:response element?
  Regards,
  --
  Peter Raymond - MERANT
  Principal Architect (PVCS)
  Tel: +44 (0)1727 813362
  Fax: +44 (0)1727 869804
  mailto:Peter.Raymond@merant.com
  WWW: http://www.merant.com
Received on Wednesday, 6 February 2002 12:28:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT