On Tue, Oct 14, 2008 at 11:21:43PM +0100, Dave Cridland wrote: > Where Postel's Law applies is that XMPP speakers need to cope with XML > which *is* well-formed, but might not be namespace well-formed. This, I'll > call Bad XMLNS.
Nice coinage :). I don't think Postel's Law should have to apply in either case (except in the interim period where we're forced to deal with Bad XMLNS). >> I think this is ideal; bad producers never have a chance to enter the >> ecosystem. >> >> > But they have and do. It's not very often, I agree, but by stating that > this situation exists, and you mustn't - or shouldn't - choke on it, I > think we're documenting the facts as they are, not as we might wish them to > be. They do? Are there any widely deployed clients that generate Bad XML, or servers that pass it on? (Note that I'm just talking about plain Bad XML here, the point was to demonstrate that refusing to handle Bad XML has had certain benefits and that refusing to handle Bad XMLNS can have similar ones.) > Please, Brendan, I'm getting increasingly fed up with this persistent > rumour that solving this issue in clients requires some kind of special > parser, or difficult programming, or voodoo in the dead of night. I certainly didn't mean to imply anything like that. Having to handle Bad XMLNS limits the parsers a client can use. Not all parsers will accept Bad XMLNS. Many people are already familiar with XML parsers that don't. Some platforms may not have XML parsers that do. It seems to me that the simplest solution is to follow the XML specifications that we claim to be using.
pgpYlgxIaWNPu.pgp
Description: PGP signature
