W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: XML InfoSet and property value preservation

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Nov 2005 11:22:53 +0100
Message-ID: <437C59FD.9000300@gmx.de>
To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
CC: webdav WG <w3c-dist-auth@w3.org>

Wilfredo Sánchez Vega wrote:
> 
>    Hate to sound ignorant again, but, well I guess I don't hate it
> that much...
> 
>    Recognizing that we can't say that XML sub-elements aren't allowed
> in property elements because of history, the spec should encourage

XML sub-elements *are* allowed in property values. RFC2518 says this, 
and many servers get this right.

> clients that want to know that their data will be preserved exactly
> as-is (comments and all) SHOULD encode their content, and perhaps the
> spec should recommend an encoding (eg. escaped XML/CDATA) for
> property contents.  This has the advantage of working reliably on
> 100% of existing servers, regardless of how they expand namespaces,
> ignore comments (or not), use CDATA or escaped XML, etc.

If a client really expects the property value to be treated as text, 
yes, it should send it as text.

The issue here that there are very good reasons to use XML, for 
instance, when the format of the property is already defined as XML 
(such as when tunneling DC metadata in WebDAV properties).

>    Clients putting sub-elements into properties should accept that
> the server will likely parse those elements, potentially storing that
> into some normative form, then re-render that into XML when asked for
> it later, and that semantically equivalent but byte-for-byte
> different data may come back.  I think forcing a server author to
> care about preserving the original XML rendering at all is a bad idea.

As far as I can tell, nobody asked for that.

>    WebDAV is already pretty complicated.  XML with namespaces is no
> small part of that complexity. Why make it harder when an easy
> solution is already available in current implementations?

We don't want to make it harder. On the other hand, we also don't want 
to remove something I feel is an important feature, just because some 
servers do not get it right (usually, these are the same servers that 
don't get other things right as well, so trying to please those usually 
would mean taking out lots of other things).

Best regards, Julian
Received on Thursday, 17 November 2005 10:23:57 GMT

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