> I called this out in 7395 because both stream features and errors > traditionally use the 'stream' prefix while relying on the opening <stream> > tag to define to define the prefix. But for WebSocket there is no parent > <stream> tag providing those declarations, and it seemed like an easy item for > implementors to either miss entirely or do incorrectly like so: > > // Not define the namespace or prefix at all <stream:features /> <stream:error > /> > > // Define the namespace without a prefix, while still using a prefix > <stream:features xmlns="http://etherx.jabber.org/streams"; /> <stream:error > xmlns="http://etherx.jabber.org/streams"; /> > > // Stamp 'jabber:client' as the namespace because it has no xmlns attribute > <stream:error xmlns="jabber:client" /> <stream:features xmlns="jabber:client" > /> > > — Lance
Yes, there we saw there is a statement somewhere in the RFC that you should use the prefix "stream" ...if you use a prefix. I think this confuses many developers, as we have seen implementations that refuse fragments as invalid xml if it does not have a prefix (but declares the ns for the element) or uses a prefix differently to stream. This gives us problems when using EXI, as it will normally just produce valid xml. Therefore, it is up to the codec to just assign a namespace to any prefix (if necessary). There are flags/codec options defined in the EXI standard for exactly this (namespace preservation), but it reduces performance (as you have to communicate every use prefix), does not work when you build it from a memory representation and is a quirks mode IMHO. Maybe it would be good to give some more implementation notes/advice to clarify what is valid and what is not? /Johannes _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
