Subject: RE: WebDAV property schema lookup

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 6 Apr 2002 15:54:16 -0500

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:34:05 +0200

Geoff,

in general agree that when defining marshalling formats, extensibility
should be planned in and thus attributes can be problematic.

In this particular case however:

- Marshalling data type information using the xsi:type attribute is defined
in XML Schema (datatypes) and already is done in other protocols (like
SOAP). So here I think we should benefit from existing infrastructure (for
instance existing libraries that support XML Schema datatypes)

- WebDAV's multistatus format isn't very extensible itself (although it uses
elements). To be extensible, the actual propery values would need one
additional wrapper, such as:

<response>
  <href>...</href>
  <propstat>
    <prop>
      <wrapper>
        <one-dead-property>...</one-dead-property>
      </wrapper>
      <wrapper>
        <one-dead-property2>...</one-dead-property2>
      </wrapper>
   </prop>
  </propstat>
  ...

or

<response>
  <href>...</href>
  <propstat>
    <prop>
      <one-dead-property>...</one-dead-property>
   </prop>
    <prop>
      <one-dead-property2>...</one-dead-property2>
   </prop>
  </propstat>
  ...

However we don't have that, which makes extending property values using
elements harder than using attributes.

Julian

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Saturday, April 06, 2002 10:54 PM
> To: DAV