Thanks for all the replies. I agree that this should probably be clarified as the current explanation is not as clear as it should be. It looks as if you'd need to use the "stream:" prefix for "features" but you shouldn't/mustn't use it for "error". More examples or writing it in a better way would help, I assume.
Best, Michael 2015-02-03 10:53 GMT+01:00 Hund, Johannes <johannes.h...@siemens.com>: > > 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 > _______________________________________________ >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
