W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: PROPFIND allprop with more properties (was AW: Resource class )

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 30 May 2001 23:05:42 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1032D8E91@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
Cc: "Jim Whitehead (E-mail)" <ejw@cse.ucsc.edu>
Julian makes a good point about whether or not white-space is
left around as the result of "ignoring" unknown XML elements.
My personal vote is that when you "ignore" an XML element, you
should also "ignore" white space on either side of that XML element.

JimW: This probably should go on the WebDAV issues list.
In particular, as part of that issue (or possibly another
related issue), we should fix section 23.3.1, so that it
no longer makes misleading statements about the XML spec
(and preferably, declare that for WebDAV, <x></x> is equivalent
to <x/>.

Julian: If you have a chance to do some interoperability testing
with the "unknown element" nested inside of <allprop/>,
that would be great, since that would give us a basis for
fixing 23.3.1 (i.e. without introducing interoperability
issues for existing servers).


-----Original Message-----
From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]
Sent: Tuesday, May 29, 2001 3:55 PM
To: Clemm, Geoff; ietf-dav-versioning@w3.org
Subject: RE: PROPFIND allprop with more properties (was AW: Resource
class )

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Tuesday, May 29, 2001 9:23 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: PROPFIND allprop with more properties (was AW: Resource
> class )
> (Warning: detailed multi-spec language lawyering to follow :-)
>    From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de]
>    > From:  Clemm, Geoff
>    > ... you could nest the
>    > DAV:include node inside the DAV:allprop, rather than inside the
>    > DAV:propfind, i.e.
>    >
>    >  <propfind xmlns="DAV:">
>    >   <allprop>
>    >    <include>
>    >     <checked-in/><checked-out/><version-name/>
>    >    </include>
>    >   </allprop>
>    >  </propfind>
>    Well, that would be invalid for the same reason (I think).
> Now that's an interesting question.  According to section 14 of RFC

Yes, it is :-) That's why I tried to carefully phrase my last reply..

> 2518, a server that didn't understand the DAV:include element must
> ignore it (and its children).  So the question then is, what does
> "ignore" mean?  In particular, does the result of "ignoring" the
> include element in:
>  <allprop> <include>...</include> </allprop>
> have to be:
>  <allprop> </allprop>
> or could it be:
>  <allprop/>

I'd say, if the request was

<allprop> <include>...</include> </allprop>

the result of "ignoring" would indeed be:

<allprop> </allprop>

However, if the request was


it would surely be

<allprop></allprop>, which for all practical purposes is the same as

> According to the XML standard, these are equivalent, so either one of
> these is fine.  There is an "interoperability" recommendation that

Not really -- the first variation contained a text node with whitespace, so
it wan't empty...

> empty tags be used if and only if the DTD explicitly declares it to be
> EMPTY, where interoperability is defined as:
> "A non-binding recommendation included to increase the chances that
> XML documents can be processed by the existing installed base of SGML
> processors".
> Since the chances of using an existing SGML processor to parse WebDAV
> response messages is vanishingly small, the only sensible approach
> would be for WebDAV to ignore this "non-binding recommendation".  For
> some reason, Section 23.3.1 of RFC 2518 (incorrectly) states that "It

I agree that this statement needs to be removed.

> is a violation of the XML specification" to do otherwise.  Perhaps
> JimW or some other 2518 author can explain the rationale behind this?
> So in summary, nesting the <DAV:include> inside of the <DAV:allprop>
> would be illegal only by a certain interpretation of "ignore",
> combinded with the (incorrect) statements made by 23.3.1 about the use
> of empty element tags.
> (language-lawyering off :-)

I feel you're right.

How do we proceed?

I've done interoperabilty tests with "our" version of the include element
(with mod_dav, IIS and Sharepoint). Should I redo them using "your" format
before we proceed with one of them?

>    > Julian: Why would you prefer to have WebDAV extensions defined
>    > through the IETF (such as DeltaV and ACL) use their own
>    > namespaces?  There clearly is a reason to define non-IETF
>    > standardized properties in their own namespace, but it is simpler
>    > to just have all IETF WebDAV extensions use the DAV: namespace.
>    Other to make it simpler to find out to which spec a "new" property
>    belongs to? No. Right now we have the unfortunate situation that
>    deltaV defines live properties in the DAV: namespace which could
>    apply to base WebDAV as well -- so for an implementor it's not
>    obvious where to find the definition.  Additionally, deltaV
>    requires a change in the RFC2518-defined behaviour for <allprop>,
>    which should be defined in the base WebDAV spec instead...
> This assumes that the definition of a property will over time remain
> in a single RFC.  I don't think this is likely.  In particular, there
> are several properties currently defined by the deltav spec that over
> time may well migrate into the "base WebDAV" protocol
> (e.g. DAV:supported-live-property-set).  If so, the only thing you
> will be able infer from the namespace of a property is that it was
> "first defined" in RFC XYZ, but that is of neglible value.

Sure. That's why I would like to see those moved out of deltaV (and into
RFC2518's successor).

> So I believe putting all IETF standardized WebDAV properties into the
> DAV: namespace is the best approach.  Save the other namespaces for
> properties introduced by non-IETF standards (which therefore require
> their own namespaces to avoid name clashes).
Received on Wednesday, 30 May 2001 23:01:03 UTC

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