Jonathan Chayce Dickinson
chayce.za at gmail.com
Mon Sep 3 15:32:34 UTC 2007
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:
> On Mon, Sep 03, 2007 at 04:18:29PM +0200, Jonathan Chayce Dickinson wrote:
>> <message [...]>
>> <body preserve="true">
>> Console:P("The console print method.");
> 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'/>
> (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
email: chayce.za at gmail.com
jabber: moitoi at inflecto.org
<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards