Subject: RE: Proposal for marshalling property type information

From: [email-masked]
Date: Mon, 18 Jun 2001 10:07:18 +0100

"Julian Reschke" <[email-masked]> wrote:
> Now I'm tempted to agree that these should be returned. A minor
> issue is with DAV:getlastmodified, because it's format isn't
> xs:dateTime, meaning that we have to define a datatype for it in
> the spec. That's why I'd still prefer to leave them out.

Whatever, the set of relevant properties is so small I don't think there is
a problem either way.

> > > I see. Maybe this should be put onto the issues list then (for
> > > resolution in RFC2518).
> >
> > What is the issue? I don't think that there is any great harm to
> > interop if
> > some servers respond with 200OK and others return 207MultiStatus
> > with 200OK
> > for each response.
>
> The issue is that after reading the spec (and tracing IIS), authors
> of client software might think that they'll always get a 207 which
> apparently isn't the case (so I think this should be clarified).

"...and tracing IIS..." thanks for the smile<g>

I agree that clarification is good.  As an aside, I wonder what a client
would do if it received an unexpected 200 OK back from a PROPPATCH -- would
a reasonable implementation really signal a failure?

> > > Do you think it would be a problem to require the 207 <multistatus>
> > > response in this case?
> >
> > You may get pushback from some server writers.
>
> Well, unless somebody suggests a better approach, I'll have to live with
> that.

Maybe you can get a few minutes in the London meeting to gauge feedback.
The problem, of course, is that if people don't like it, they won't
implement it.

Regards,
Tim

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 18 Jun 2001 21:54:31 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Monday, June 18, 2001 11:07 AM
> To: WebDAV WG
> Subject: RE: Proposal for marshalling property type information
>
>
>
>

OK, this allows me to avoid specifying a datatype for RFC dates in the spec.

> a reasonable implementation really signal a failure?

Depends on what you call reasonable. I haven't written a client yet, but up
until your comment I would have been tempted to think I'll always get a
multistatus.

> The problem, of course, is that if people don't like it, they won't

Which meeting?

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 18 Jun 2001 23:57:11 +0200

Attached is an updated version of my proposal which should address Tim's
concerns (Tim, thanks for the feedback!).
--

Network Working Group                                         J. Reschke
Internet-Draft                                                greenbytes
Expires: December 17, 2001                                 June 18, 2001

                    Datatypes for WebDAV properties
               draft-reschke-webdav-property-datatypes-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 17, 2001.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This specification extends the WebDAV Distributed Authoring Protocol
   to support datatyping on property values.  Protocol elements are
   defined to let clients and servers specify the type of a property,
   and to instruct the WebDAV method PROPFIND to return datatype
   information.

   Distribution of this document is unlimited.  Please send comments to
   the Distributed Authoring and Versioning (WebDAV) working group at
   [email-masked][1], which may be joined by sending a message
   with subject "subscribe" to [email-masked][2].

   Discussions of the WEBDAV working group are archived at URL:

Reschke                 Expires December 17, 2001               [Page 1]

Internet-Draft       Datatypes for WebDAV properties           June 2001

   http://lists.w3.org/Archives/Public/w3c-dist-auth/.

Table of Contents

   1.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of data types . . . . . . . . . . . . . . . . . . . .  5
   4.  Changes for PROPPATCH method . . . . . . . . . . . . . . . . .  6
   4.1 Example for successful PROPPATCH . . . . . . . . . . . . . . .  6
   4.2 Example for failed PROPPATCH . . . . . . . . . . . . . . . . .  7
   5.  Changes for PROPFIND method  . . . . . . . . . . . . . . . . .  9
   5.1 Example for PROPFIND/prop  . . . . . . . . . . . . . . . . . .  9
   6.  Compatibility Considerations . . . . . . . . . . . . . . . . . 11
   7.  Internationalization Considerations  . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Copyright  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Intellectual Property  . . . . . . . . . . . . . . . . . . . . 15
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17

Reschke                 Expires December 17, 2001               [Page 2]

Internet-Draft       Datatypes for WebDAV properties           June 2001

1. Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The term "property element" refers to the XML element that identifies
   a particular property, for instance

   	<getcontentlength xmlns="DAV:" />

   The term "prop element" is used for the WebDAV "prop" element as
   defined in section 12.11 of [RFC2518].

   The XML representation of schema components uses a vocabulary
   identified by the namespace name "http://www.w3.org/2001/XMLSchema".
   For brevity, the text and examples in this specification use the
   prefix "xs:" to stand for this namespace; in practice, any prefix can
   be used.  "XML Schema: Structures" ([XS1]) also defines several
   attributes for direct use in any XML documents.  These attributes are
   in a different namespace, which has the namespace name
   "http://www.w3.org/2001/XMLSchema-instance".  For brevity, the text
   and examples in this specification use the prefix "xsi:" to stand for
   this latter namespace; in practice, any prefix can be used.

Reschke                 Expires December 17, 2001               [Page 3]

Internet-Draft       Datatypes for WebDAV properties           June 2001

2. Introduction

   This specification builds on the infrastructure provided by the
   WebDAV Distributed Authoring Protocol, adding support data-typed
   properties.

   Although servers must support XML content in property values, it may
   be desirable to persist values as scalar values when possible, and to
   expose the data's type when the property value is returned to the
   client.  The client is free to ignore this information, but it may be
   able to take advantage of it when modifying a property.

   On the other hand, when setting new properties, it can be desirable
   to pass data type information along with the value.  A server can
   take advantage of this information to optimize storage and to perform
   additional parsing (for instance of dates).

Reschke                 Expires December 17, 2001               [Page 4]

Internet-Draft       Datatypes for WebDAV properties           June 2001

3. Overview of data types

   Although WebDAV property types can be anything that can be marshalled
   as content of an XML element, in many cases they actually are simple
   types like integers, booleans or dates.  "XML Schema Part 2:
   Datatypes" [XS2] defines a set of simple types which can be used as a
   basis for supplying type information to attributes.

   Data type information is represented using the attribute "type" from
   the XML Schema namespace "http://www.w3.org/2001/XMLSchema-instance".
   In XML Schema, data types are qualified names, and the XML Schema
   recommendation defines a set of built-in datatypes (section 3 of
   [XS2]), defined in the namespace "http://www.w3.org/2001/XMLSchema".

   To avoid unnecessary verbosity, data type information should only be
   supplied if it adds usable information to the protocol.  In
   particular, type information is not required for live properties
   defined in WebDAV [RFC2518] and related standards and properties of
   type "xs:string".

   A server may implement any combination of datatypes, both from the
   XML Schema recommendation and possibly from other namespaces.

Reschke                 Expires December 17, 2001               [Page 5]

Internet-Draft       Datatypes for WebDAV properties           June 2001

4. Changes for PROPPATCH method

   If the property element has an XML attribute named "xsi:type", the
   server may use this information to select an optimized representation
   for storing the property value.  For instance, by specifying a type
   as "xs:boolean", the client declares the property value to be of type
   boolean (as defined in [XS2]).  The server may choose any suitable
   internal format for persisting this property, and in particular is
   allowed to fail the request if the format given does not fit the
   format defined for this type.

   The server should indicate successful detection and parsing of the
   typed value by setting the xsi:type attribute on the property element
   in the response body (this implies that it should return a
   MULTISTATUS status code and a <multistatus> response body).

4.1 Example for successful PROPPATCH

    >>Request

      PROPPATCH /bar.html HTTP/1.1
      Host: www.foo.com
      Content-Type: text/xml
      Content-Length: xxxx

      <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">
        <D:set>
          <D:prop>
            <Z:released xsi:type="xs:boolean">false</Z:released>
           </D:prop>
        </D:set>
      </D:propertyupdate>

Reschke                 Expires December 17, 2001               [Page 6]

Internet-Draft       Datatypes for WebDAV properties           June 2001

    >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml
      Content-Length: xxxx

      <D:multistatus 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">
        <D:response>
          <D:href>http://www.foo.com/bar.html</D:href>
          <D:propstat>
            <D:prop><Z:released xsi:type="xs:boolean" /></D:prop>
            <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
        </D:response>
      </D:multistatus>

   In this cases, the xsi:type attribute on the element "Z:released"
   indicates that the server indeed has understood the submitted data
   type information.

4.2 Example for failed PROPPATCH

    >>Request

      PROPPATCH /bar.html HTTP/1.1
      Host: www.foo.com
      Content-Type: text/xml
      Content-Length: xxxx

      <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">
        <D:set>
          <D:prop>
            <Z:released xsi:type="xs:boolean">t</Z:released>
           </D:prop>
        </D:set>
      </D:propertyupdate>

Reschke                 Expires December 17, 2001               [Page 7]

Internet-Draft       Datatypes for WebDAV properties           June 2001

    >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml
      Content-Length: xxxx

      <D:multistatus xmlns:D="DAV:"
         xmlns:Z="http://www.w3.com/standards/z39.50">
        <D:response>
          <D:href>http://www.foo.com/bar.html</D:href>
          <D:propstat>
            <D:prop><Z:released/></D:prop>
            <D:status>HTTP/1.1 422 Unprocessable Entity</D:status>
            <D:responsedescription>Does not parse as
xsd:boolean</D:responsedescription>
          </D:propstat>
        </D:response>
      </D:multistatus>

   In this case the request failed because the supplied value "t" is not
   a valid representation for a boolean value.

Reschke                 Expires December 17, 2001               [Page 8]

Internet-Draft       Datatypes for WebDAV properties           June 2001

5. Changes for PROPFIND method

   PROPFIND is extended to return the data type information for
   properties unless one of the following conditions is met:

   o  The data type MUST be different from "xs:string" (because this can
      be considered the default data type).

   o  The property's data type MUST not defined in [RFC2518] (because
      these types are already well-defined).

5.1 Example for PROPFIND/prop

   >>Request

      PROPFIND /bar.html HTTP/1.1
      Host: www.foo.com
      Content-Type: text/xml
      Content-Length: xxxx

      <D:propfind xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50">
        <D:prop>
          <D:getcontenttype/>
          <Z:released/>
        </D:prop>
      </D:propfind>

Reschke                 Expires December 17, 2001               [Page 9]

Internet-Draft       Datatypes for WebDAV properties           June 2001

    >>Response

      HTTP/1.1 207 Multi-Status
      Content-Type: text/xml
      Content-Length: xxxx

      <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">
        <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">1</Z:released>
            </D:prop>
            <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
        </D:response>
      </D:multistatus>

   This example shows that the property value "true" is returned with
   the correct data type information, and that the server chose one of
   the two possible representations defined in XML Schema.  It also
   shows that data type information is not returned for
   "D:getcontenttype", as this property's data type is already defined
   in [RFC2518].

Reschke                 Expires December 17, 2001              [Page 10]

Internet-Draft       Datatypes for WebDAV properties           June 2001

6. Compatibility Considerations

   This specification does not introduce any new protocol elements, nor
   does it change the informal WebDAV DTD.  It merely specifies
   additional server semantics for the case where clients submit
   additional data type information in an attribute on the property
   element (previously undefined), and adds an additional attribute on
   property elements upon PROPFIND.

   Clients not aware of this specification should not supply the
   "xsi:type" attribute on property elements (after all, this attribute
   belongs to the XML Schema-Instance namespace which has been defined
   for exactly this purpose).  Old clients should also ignore additional
   attributes on property elements returned by PROPFIND (and similar
   methods), although the WebDAV specification only defines this
   behaviour for unknown elements (and is silent about unknown
   attributes).

   Servers not aware of this specification either drop the "xsi:type"
   attribute, or persist it along with the property value.  However,
   they will never indicate successful parsing of the data type by
   returning back the type in the response to PROPPATCH.

Reschke                 Expires December 17, 2001              [Page 11]

Internet-Draft       Datatypes for WebDAV properties           June 2001

7. Internationalization Considerations

   This proposal builds on [RFC2518], and inherits its
   internationalizability.

Reschke                 Expires December 17, 2001              [Page 12]

Internet-Draft       Datatypes for WebDAV properties           June 2001

8. IANA Considerations

   This proposal does not introduce any new IANA considerations, since
   it does not specify any new namespaces (in the general sense), but
   merely uses existing ones.

Reschke                 Expires December 17, 2001              [Page 13]

Internet-Draft       Datatypes for WebDAV properties           June 2001

9. Copyright

   To be supplied by the RFC Editor.

Reschke                 Expires December 17, 2001              [Page 14]

Internet-Draft       Datatypes for WebDAV properties           June 2001

10. Intellectual Property

   To be supplied by the RFC Editor.

Reschke                 Expires December 17, 2001              [Page 15]

Internet-Draft       Datatypes for WebDAV properties           June 2001

References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
              World Wide Web Consortium, "Extensible Markup Language
              (XML) 1.0", W3C XML, February 1998,
              <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [XS1]      Thompson, H., Beech, D., Maloney, M., Mendelsohn, N. and
              World Wide Web Consortium, "XML Schema Part 1:
              Structures", W3C XS1, May 2001,
              <http://www.w3.org/TR/xmlschema-1/>.

   [XS2]      Biron, P., Malhotra, A. and World Wide Web Consortium,
              "XML Schema Part 2: Datatypes", W3C XS2, May 2001,
              <http://www.w3.org/TR/xmlschema-2/>.

   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
              Jensen, "HTTP Extensions for Distributed Authoring --
              WEBDAV", RFC 2518, February 1999.

   [1]  <mailto:[email-masked]>

   [2]  <mailto:[email-masked]?subject=subscribe>

Author's Address

   Julian F. Reschke
   greenbytes GmbH
   Salzmannstrasse 152
   Muenster, NW  48159
   Germany

   EMail: [email-masked]

Reschke                 Expires December 17, 2001              [Page 16]

Internet-Draft       Datatypes for WebDAV properties           June 2001

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Reschke                 Expires December 17, 2001              [Page 17]


> -----Original Message-----
> [mailto:[email-masked]]On Behalf Of Julian Reschke
> Sent: Monday, June 18, 2001 9:55 PM
> To: [email-masked]; WebDAV WG

---

From: "Tim Ellison" <[email-masked]>
Date: Tue, 19 Jun 2001 08:17:01 +0100

> > The problem, of course, is that if people don't like it, they won't

IETF51 which is being held in London
(http://www.ietf.org/meetings/IETF-51.html)

Tim

---

From: "Eric Sedlar" <[email-masked]>
Date: Tue, 19 Jun 2001 06:59:58 -0700

This spec is cool.  I think it should be folded into the new RFC2518.

> Sent: Monday, June 18, 2001 2:57 PM
> To: WebDAV WG

---

From: "Dan Brotsky" <[email-masked]>
Date: Mon, 25 Jun 2001 12:23:47 -0700

I also like Julian's proposal and would be glad to see it 
incorporated into 2518.  But there are a few questions related to 
live properties that I'm hoping Julian and others would comment on:

1. I work on a number of servers that have specialized live 
("computed" in the deltaV sense) properties for workflow tracking. 
It seems that we could use the extended PROPFIND to indicate to 
clients the datatype of those properties, but Julian only shows an 
example where the client has indicated the datatype.  Were live 
properties expected to obey the same extension rule?  If so we might 
want to clarify this and add an example.

2.  Some of my servers implement "type-restricted" live properties 
which are essentially dead properties whose values are restricted to 
a certain datatype.  These servers will reject PROPPATCH requests 
that use the wrong datatype whether or not the client has declared a 
datatype in the PROPPATCH.  Julian's proposal shows an example of a 
422 response when the PROPPATCH-declared datatype doesn't match the 
datatype of the value; I would also like to use such a response when 
the value's datatype doesn't match the PROPFIND-shown (and enforced) 
datatype.  How does this strike people?

     dan
-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Eric Sedlar" <[email-masked]>
Date: Mon, 25 Jun 2001 20:18:03 -0700

I like it!

> [mailto:[email-masked]]On Behalf Of Dan Brotsky
> Sent: Monday, June 25, 2001 12:24 PM
> To: WebDAV Working Group

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 30 Jun 2001 20:54:51 +0200

> Sent: Monday, June 25, 2001 9:24 PM
> To: WebDAV Working Group

Correct.

> want to clarify this and add an example.

Good idea. Which example should I take? Maybe som property from the deltaV
spec?

> datatype.  How does this strike people?

I think this would make sense. Do we need clients to be able to distinguish
between both error conditions?