RE: XML in LOCK <owner> tag should be self-contained

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