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

> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
>
> [...]
> 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).

Ok, our tests showed that
<allprop/><include>...</include>
   works with moddav, IIS and our servlet, while
<allprop><include>...</include></allprop>
   works with moddav and IIS. Julian's PROPFIND
   handler is throwing the book at me with 422s.

However our code is not in production and can easily
be changed by twisting Julian's arm a little. Sitting
opposite of him helps.

If anyone else has a public server which I should test,
please let me know.

//Stefan


> Cheers,
> Geoff
>
> -----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
>
> <allprop><include>...</include></allprop>
>
> it would surely be
>
> <allprop></allprop>, which for all practical purposes is the same as
> <allprop/>.
>
> > 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 Friday, 1 June 2001 08:00:25 UTC