W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001

RE: Proposal for marshalling property type information

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 15 Jun 2001 16:17:44 +0200
To: <Tim_Ellison@uk.ibm.com>, "WebDAV WG" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCAEHGCHAA.julian.reschke@gmx.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Tim_Ellison@uk.ibm.com
> Sent: Friday, June 15, 2001 2:05 PM
> To: WebDAV WG
> Subject: RE: Proposal for marshalling property type information
>
>
>
>
> "Julian Reschke" <julian.reschke@gmx.de> wrote:
>
> > Understood. So would it possibly make sense to to change
> > the wording to "he property's data type is defined in [RFC2518]"
> > (leaving other specifications out)? I still think we don't
> > need to return the types for RFC2518 defined properties...
>
> The RFC2518 defined properties are:
> creationdate
> displayname
> getcontentlanguage
> getcontentlength
> getcontenttype
> getetag
> getlastmodified
> lockdiscovery
> resourcetype
> source
> supportedlock
>
> So the only ones that I believe would return type info (using the
> xs:string
> - exclusion rule) are
> creationdate -> dateTime
> getContentLength -> nonNegativeInteger
> getLastModified -> dateTime

Tim, thanks for the summary.

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.

> So although I don't think it would be a great overhead for servers to
> return these each time, I don't really care either way.
>
> > > It was generally agreed on this list a while back that total
> > > success may be condensed to a simple 200 OK response.  Your
> > > suggestion would require a further modification to these servers.
> >
> > 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).

> > 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.
Received on Friday, 15 June 2001 10:18:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:56 GMT