Re: [Bug 10] Round-tripping namespace decls in properties

Wilfredo,

thanks for the feedback. In our conference call, when we discussed this, 
the rational was that if we want server implementors to implement this 
at some point int the future, we need to tell them now. This is not 
extraordinary when upgrading specs.

More comments:

> I still maintain that it is unreasonable to require a server to preserve namespace prefixes.  WebDAV 
> requires that server authors understand XML and XML namespaces.

That is correct.

> Adding requirements imposed by additional specifications (XSLT, etc.) puts an undo burden on server 
> authors, given that some XML libraries, when asked to simply read XML into a DOM and then render 

I think this is a misunderstanding. Preserving prefixes is not "imposed" 
by additional specifications. There was never any W3C spec that said 
that prefixes are irrelevant (or, if there is, please let me know).

> that XML *do* rewrite namespace prefixes.  If a server author can't simply ask a library to render the 
> XML and instead has to dive into the innards of the library or write their own renderer, you've obviated 
> the alleged value of using XML in the first place.  Dealing with XML in WebDAV is hard enough as things 
> are.

Yes, and I confess that some years ago, I wrote a library in which I 
also deliberately threw away prefixes.

On the other hand, I really can't think of any W3C spec that licenses 
parsers or serializers to throw out prefix information. Server 
implementors will just have to make sure that the libraries they use 
work properly (just as for other less-well understood XML features).

> This is especially bothersome given that if a client cares about preserving XML exactly as given, than a 
> simple encoding of the XML will guarantee that, and the server can remain blissfully ignorant of that 
> content.  If you instead put the XML elements in a property, the server *has to* parse them, and clients 
> should be willing to accept the consequenses of that.

Escaping XML so it becomes string data solves one problem, but creates 
lots of others (including weird display in generic clients, and 
surprising results in SEARCH requests). So I really don't buy in it 
being a proper solution to this problem in the generic case.

Best regards, Julian

Received on Friday, 9 December 2005 10:04:49 UTC