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

RE: Marshalling Depth > 0 responses for REPORTs, WAS: Replacing t he Label header with a DAV:labeled-version report

From: Julian Reschke <julian.reschke@greenbytes.de>
Date: Sun, 28 Jul 2002 18:29:26 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCEEJFFAAA.julian.reschke@greenbytes.de>

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, July 28, 2002 4:03 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: Marshalling Depth > 0 responses for REPORTs, WAS: Replacing
> t he Label header with a DAV:labeled-version report
> Summary of the issue:
> Julian would like to move the marshalling of Depth REPORT responses
> from the DAV:prop node in a DAV:response to a new DAV:report-result
> node in the DAV:response.
> Summary of my response:
> RFC3253 states that the marshalling is in the DAV:prop node, and
> we should not change that unless there is some significant problem
> with that marshalling.  I see no such problem, and therefore vote
> to leave the spec as it is.

Well, the most significant problem with this kind of marshalling is that
it's completely non-obvious, and there's no example in the spec. So again my
question to deltaV-implementors: who has REPORTs with depth != 0 currently
implemented and is compatible to RFC3253?

> Detailed response below:
>    From: Julian Reschke [mailto:julian.reschke@gmx.de]
>    IMHO, marshalling something that isn't a resource property inside a
>    multistatus/response/propstat/prop element clearly breaks RFC2518
>    [1] and is very confusing.
> I disagree on both counts.
> RFC2518 says nothing about a REPORT method, so the response format of
> a REPORT method cannot break RFC2518.  We have already concluded that
> in earlier threads that each method effectively introduces a new DTD
> for any XML elements in the response body.

RFC3253 states that for depth != 0, the response must conform to whatever
RFC2518 has to say about Multi-Status response bodies. Please don't say it
doesn't, because in that case the response format is completely undefined.

> So that leaves the question of whether it is "confusing".  I agree
> that it is desireable to have consistent DTD's for a standard XML
> element, across all methods (preferably even across request and
> response bodies).  But the only difference between a "report result"
> and a "live property value" is that a report can take arguments that
> modify the result ("value") of that report for a given resource.  In
> particular, a report that has a default value for omitted arguments
> acts exactly like a "live property".

See, and this exactly the thing that I think is wrong. There should be no
doubt whether something is a (live) property or not. To marshall something
as property because it "acts exactly like" a property conflates separate

> So in the interest of keeping the DTD's of standard XML elements
> consistent, I believe it is desireable to avoid having a standard
> report result XML element be the same as a standard property value XML
> element, to avoid having significantly different DTD's for the same
> standard XML element.  This is what is indicated in RFC3253 by having
> the report result appear in the same context (i.e. under a DAV:prop
> element) as property values.

Wow! Do you say that by this approach RFC3253 forbids other specs to define
properties with names matching existing REPORT result elements? If this *is*
the intention, it should be made clear.

>    If this behaviour really was intended by RFC3253 then it was
>    extremely hard to discover because there's not a single example in
>    the spec where this actually happens.
> I see no other possible interpretation for the statement in 3.6:
> "The DAV:prop element of a DAV:response for a given resource MUST
> contain the requested report for that resource."
> I'm happy to add an example in the next version of the spec, if
> you feel this needs to be clarified.

I absolutely feel so.

>    My proposal would be to put the report result below the
> response element,
>    and to assign it a new name, such as:
>    <response>
>      <href>...</href>
>      <status>...</status>
>      <report-result>...</report-result>
>    <response>
> We could do so, but this violates 3253, which requires the report
> to be placed in the DAV:prop element.  I agree that this is a
> reasonable alternative marshalling, and if we didn't have 3253
> saying otherwise, I'd be pretty happy to do it either way, but
> I'd like to only change 3253 for serious problems.

I think by now we can safely assume that we won't get any kind of
interoperability for these kinds of reports unless we clarify the format. I
haven't seen any server or client implementing the current RFC3253 format
yet, so I think clarifying *plus* choosing a more logical format makes a lot
of sense.

> ...
Received on Sunday, 28 July 2002 12:30:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC