- From: Clemm, Geoff <gclemm@rational.com>
- Date: Mon, 23 Sep 2002 09:39:48 -0400
- To: w3c-dist-auth@w3.org
I believe that in general we need to distinguish what the spec should say to allow for client/server interop, and what a "interop guide" should say about interoperating with poorly implemented clients or servers. For this particular thread, a client should be able to send legal XML, especially since the client will often be using a generic XML parsing/unparsing package that doesn't have provisions for "replicating" namespace declarations within certain nodes. So I agree with suggestion 1 (i.e. servers should handle this case correctly), and disagree with suggestions 2, 3, and 4. To emphasize, I'm happy to have an "interop guide" document that tells a client about this particular server bug, and how to workaround it, but I would object to placing this language/advice in the protocol. A client should not be forced to work around server bugs (although it of course is free to do so), and the spec should not be made more complex or harder to implement just to provide interoperability with buggy servers. Cheers, Geoff From: Julian Reschke [mailto:julian.reschke@gmx.de] I think this is identical to the problem of how faithfully the namespace prefixes are preserved inside dead properties. IMHO - namespace information must be preserved (hopefully this is obvious) - namespace prefixes on elements *inside* property values should be preserved - namespace declarations that are needed but appeared outside the actual property may be returned anywhere recreating the correct scope This should then also apply the content of the DAV:owner element. From: John Spaith At the WebDAV interop fest, we saw that some servers weren't doing the right thing when clients send them <owner> tags on a LOCK request. When doing a LOCK a client can put in XML in the owner tag, and this XML often times has namespaces prefixes in it. So we have something like... LOCK <xml> <lockinfo xmlns:MyNS="MyNameSpace"> [...] <owner> <MyNS:MyTag>...</MyNS:MyTag> </owner> [...] When the server returns this owner tag on a lockdiscovery, it has to also return the definition of the MyNS namespace in the <owner> tags or clients will choke on not recognizing MyNS prefix. Having to keep track of prefix mappings when parsing the LOCK body is an added piece of complexity that servers don't really need. It would be better if we could require (or more likely strongly encourage) clients to make any XML inside the <owner> tag work standalone, i.e. forcing them to define any namespaces they use there. They would send something like this on a LOCK. <owner> <MyNS:MyTag xmlns:MyNS="MyNameSpace">...</MyNS:MyTag> </owner> This way the server could just keep a copy of the data between the <owner> tags without any extra processing. Steps to increase interop: 1. Server implementers should be aware of this and code accordingly. A number of servers at the WebDAV interop fest only copied the data between <owner> tags, not doing the extra name space processing. 2. We should say something to the effect that clients SHOULD send self-contained XML data with all the namespaces prefixes they used defined between the <owner> tags to workaround servers that don't handle this correctly. 3. We should practice what we preach in the spec. For instance in RFC 2518 example 8.10.8, we have <D:href> inside an <owner> tag that could cause certain servers to have the problem described here. 4. We should keep general scenario in mind when writing specs in the future that involve one party saving XML with namespace tags in it from another party, possibly saying that the client MUST send self-contained XML. Alas, since RFC 2518 is a done-deal there's not much we can do on #3. Issues #1 and #2 are mostly education issues for WebDAV client and server implementers. The main reason I'm writing this is for #4, so that we can be aware of this scenario in the future.
Received on Monday, 23 September 2002 09:40:24 UTC