What you said is very true Michal, but you haven't taken it one step back.
If the truth be told, these clients are processing XML. The sooner they wake up and smell the coffee and use a proper XML processing framework instead of shoddy home-grown ones, the better. There are plenty frameworks out there, just plug-n-play...
And woe-be-tide if a server has the same issues (it shouldn't, because it's payload agnostic)...
XML stands for eXtensible Markup Language, note the 'extensible', you should be able to add to it without worry for backward compatibility. The fact that their client can not support extra attributes is, in reality, a *bug*.
The only reason these clients will have problems is because they are not conforming to XEP CORE. In which case, they are not our concern.
Am I not correct?Maybe a Namespace something along the lines of "http://etherx.jabber.org/new"? For stuff that 'belongs' in the core, but can't be added since it was RFC'ed.
Michal 'vorner' Vaner wrote:
Hello On Mon, Sep 03, 2007 at 04:18:29PM +0200, Jonathan Chayce Dickinson wrote:<message [...]> <body preserve="true"> (SomeClassInAStrangeProgrammingLanguage: {SomeMethod: Console:P("The console print method."); :} :) </body> </message>This one is nice. But, the preserve attribute would need to be in different language and you can not do that without namespace prefixes. Unhappily, there are many clients that yet do not support them (pity, I know). But may I suggest something like: <message …> <preserve xmlns='whatever:show:method:ns'/> <body> … </body> </message> (I agree that your way is correct too, and the clients should be fixed for sure, but attribute in a different namespace is not in any XEP I know of and may be troublesome).
-- jonathan chayce dickinson ruby/c# developer email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] <some profound piece of wisdom>
smime.p7s
Description: S/MIME Cryptographic Signature
