Subject: RE: WebDAV property schema lookup

From: Gary Cowan <[email-masked]>
Date: Sat, 6 Apr 2002 22:32:44 -0500

This situation illustrates a fundamental weakness with WebDAV in respect to
enterprise document management systems. The WebDAV philosophy assumes that
the client is controlling the properties of a resource/document and the
server mearly acts as a store for the property information. Wheras a DM
server maintains extensive metadata for a given resource especially when
vertical market applications have been built on top of the DM system. WebDAV
does not provide a methodology by which this metadata can be exposed. As
such DM systems must still construct proprietary client applications causing
users to perform authoring in the authoring tool while performing DM
specific actions in the DM client. 

At this point in time it still makes more sense for DM systems to construct
tight integration mechanisms within the context of the authoring
application. This gives the DM system the ability expose its own metadata to
the user during document creation/editing.

WebDAV is a very attractive protocol but this one limitation is inhibiting
its extensive use within the enterprise DM community. 

> ----------
> From: 	Clemm, Geoff[SMTP:[email-masked]]
> Sent: 	Saturday, April 06, 2002 3:54 PM
> To: 	DAV
> Subject: 	RE: WebDAV property schema lookup
> 
> I agree that property "metadata" should only be returned
> if the client specifically asks for it.  Along the same lines,
> I would provide a mechanism for the client to ask for specific
> metadata, since it doesn't make any sense to send back to
> the client metadata information that it doesn't understand.
> Finally, I would marshall all of this as XML elements, not as
> attributes.  XML element values are significantly more extensible
> that attribute values, and given the relative infrequency of
> asking for this metadata, the additional bytes required by
> XML elements shouldn't be an issue.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Saturday, April 06, 2002 10:51 AM
> To: Eric Sedlar
> Cc: DAV
> Subject: RE: WebDAV property schema lookup
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Eric Sedlar
> > Sent: Tuesday, April 02, 2002 10:52 AM
> > To: Julian Reschke
> > Cc: DAV
> > Subject: Re: WebDAV property schema lookup
> >
> >
> > I don't think that deciding which dead properties are editable
> > will be done
> > on the client, but rather via some server-specific mechanism.
> 
> I agree. The question being, how a server decides this for a given dead
> property (it may not be able to do it).
> 
> > For example,
> > we would probably say that all dead properties not in the DAV or Oracle
> > namespaces are editable by default, and possibly allow some
> > configuration in
> > a parameter file to list uneditable ones.
> 
> That's certainly something that *can* be done.
> 
> So how do we proceed?
> 
> - I think that what our current draft says is needed as a basis anyway
> - One possible approach would be to get into the schema / model business,
> à
> la Exchange 2000 and Sharepoint
> - A simpler approach would be to define marshalling for the additional
> information you asked for as extensions to PROPFIND/PROPPATCH
> 
> For instance, the first two things you asked for (editability and
> visibility) can trivially be marshalled in new property attributes (this
> could be easily added to our existing datatype marshalling):
> 
> Proppatch request:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propertyupdate xmlns:D="DAV:"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:set>
>     <D:prop>
>       <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false">false</Z:released>
>     </D:prop>
>   </D:set>
> </D:propertyupdate>
> 
> ..
> 
> Propfind response:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:response>
>     <D:href>http://www.foo.com/bar.html</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getcontenttype>text/html</D:getcontenttype>
>         <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false">1</Z:released>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
> 
> 
> Note that this is compatible with RFC2518 as
> 
> - old clients will never send the new attributes upon PROPPATCH
> - servers can add the two attributes two the existing property values
> transparently (because they sit in a new namespace which should be ignored
> by old clients)
> 
> 
> Adding textual descriptions is a bit harder, because it's not as easy to
> marshall them in attribute values (we need to make sure that we properly
> treat language negotation/xml:lang). I wouldn't want to send this
> information with every PROPFIND reply, so we probably would require that a
> client specifically asks for them:
> 
> Propfind request:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:propfind xmlns:D="DAV:"
>   xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:prop x:include-descriptions="true">
>     <D:getcontenttype/>
>     <Z:released/>
>   </D:prop>
> </D:propfind>
> 
> 
> Propfind response:
> 
> <?xml version="1.0" encoding="utf-8" ?>
> <D:multistatus xmlns:D="DAV:"
>    xmlns:Z="http://www.w3.com/standards/z39.50"
>    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    xmlns:xs="http://www.w3.org/2001/XMLSchema"
>    xmlns:x="http://webdav.org/property-attribute">
>   <D:response>
>     <D:href>http://www.foo.com/bar.html</D:href>
>     <D:propstat>
>       <D:prop>
>         <D:getcontenttype>text/html</D:getcontenttype>
>         <Z:released xsi:type="xs:boolean" x:hidden="true"
> x:editable="false"><x:description
> xml:lang="en">released?</x:description>1</Z:released>
>       </D:prop>
>       <D:status>HTTP/1.1 200 OK</D:status>
>     </D:propstat>
>   </D:response>
> </D:multistatus>
> 
> 
> Feedback appreciated.
> 
> Julian
>

---

From: "Julian Reschke" <[email-masked]>
Date: Sun, 7 Apr 2002 11:58:14 +0200

Gary,

I'm not sure I understand this statement...

> [mailto:[email-masked]]On Behalf Of Gary Cowan
> Sent: Sunday, April 07, 2002 5:33 AM
> To: DAV; 'Clemm, Geoff'

I don't think that RFC2518 says this. The protocol certainly allows servers
to implement a rich set of server-defined properties. For instance:

- RFC3253 implements a whole set of server-defined properties that model
versioning properties,

- Microsoft Sharepoint (although breaking WebDAV in some other aspects)
nicely exposes document metadata as WebDAV properties (for instance, it
supports document classes with inheritence, their discovery and
manipulation, mandatory typed properties...)

> does not provide a methodology by which this metadata can be exposed. As

I think this isn't true. Could you please explain this in more detail?

> specific actions in the DM client.

That sounds a bit like "existing clients do not support manipulation of our
server's properties, thus the protocol is broken". I'd say, we just need
better clients.

---

From: "Dylan Barrell" <[email-masked]>
Date: Sun, 7 Apr 2002 17:27:55 -0400

Absolutely agree - I brought this issue up a couple of months ago.

From my perspective we need two things

1) We need the ability for the server to enforce schema on documents when
they are created (we talked about a multi-put a couple of months back).
Schema descovery is also an issue as the client needs to know what the
mandatory properties are before it can issue the multi-put.

2) We need to have a way for the server to tell the client where to redirect
the user if the user want to manipulate the object in a way that is out of
scope for WebDAV - e.g. initiate a chat with the author of the document. In
fact, the server should be able to tell the client what URL to go to for
these actions as well as what client side application to spawn should it be
available.

--Dylan

> Sent: Saturday, April 06, 2002 10:33 PM
> To: DAV; 'Clemm, Geoff'

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 8 Apr 2002 09:46:51 +0200

> [mailto:[email-masked]]On Behalf Of Dylan Barrell
> Sent: Sunday, April 07, 2002 11:28 PM
> To: Gary Cowan; DAV; 'Clemm, Geoff'

Two thoughts:

a) MS Sharepoint works around this by enforcing schema compliance not on
creation, but upon CHECKIN. This may or may not be sufficient (checking in
pops up a dialogue where the user must fill all required fields).

b) Instead of inventing MULTIPUT, we may be able to use the HTTP Extension
Framework (RFC2774), defining mandatory headers for M-PUT (marshalling would
be a bit tricky, though).

> mandatory properties are before it can issue the multi-put.

Sure. But we won't get that unless a group of peope sits down and develops a
proposal.

> these actions as well as what client side application to spawn

In the general case, wouldn't that be just a link to a (dynamically
generated) HTML document (may be a new property or another use for
DAV:source :-).