[standards-jig] JEP0038 (the emoticon spec) Some suggestions
Sebastiaan 'CBAS' Deckers
cbas at screaming3d.com
Wed Sep 25 10:03:09 UTC 2002
Mattias Campe wrote:
> Sebastiaan, I know you already have an implementation of JEP038 (the
> client Rhymbox) as it can be found on
> http://www.jabber.org/jeps/jep-0038.html. And I also know that my
> suggestions aren't backward compatible with this official (but still
> experimental) JEP. I just wanted to say that I hope that you don't
> think like "Shit, if that would change, I would have to rewrite all my
> icondef.xml's (and I know that you have some of them ;) ) and my
> implementation would have to be rewritten too"...
I've rewritten the icondef.xml files lots of times. And I don't think
it would take more than 30 minutes to make the changes you propose. But
I don't see any reason why to change them because the changes *add no value*
>> What advantage does this offer compared to the lang attribute we have
>> been using the last three months? It seems like the "right" thing to
>> do, but I can't think of a more practical reason. Is there a
>> conflict between the lang attribute and something else?
> To be short: "xml:lang" is a *standard*
> (http://www.w3.org/TR/REC-xml#sec-lang-tag), "lang" isn't. If
> developers see xml:lang, some of them will *exactly* know what they
> can use. If you use just "lang", *nobody* will *exactly* know what
> this lang means, this will have to be looked up in the XML schema.
This depends on what experience the developer has, and it is never a
good idea to implement something without reading the full spec. For
example in XHTML 1.0, there is both the lang attribute and the xml:lang
attribute. There are dozens of "standards" for language identification.
I'm fine with anything, as long as it means the same as the current lang
attribute. (That it holds the same value; that it has the same default
value; and that there must be one <text/> without the language value.)
>> I think the <graphic/>, <sound/> and <format/> tags were perfectly
>> clear in the way they represent the options a client has. This
>> <object/> tag and the format attribute will IMO add ambiguity. This
>> <object/> tag could be confused with the tag defined in HTML (which
>> is in no way similar).
> Could you plz explain to me why the <object> in HTML and in my
> proposal is in *no way* similar. Could you also tell me why w3c
> started using <object> instead of just sticking with <img> and adding
> <sound> and ... This object tag (whether it is in HTML or my proposal)
> would make it possible to have a little flash movie as well as
> emoticon. And that flash movie isn't just a simple <img>, because it
> can include <sound> as well. I'm not at all saying that this flash
> thing will be supported by a client within this year, but maybe it can
> be next year (or the year after next year) and this would require
> another tag (<flash>?), or a hack into <img>, but not with <object>...
Multimedia emoticons. That's a bit over-the-top, don't you think? :-)
Nevertheless, this is already supported thanks to the lovely <x/>
element. No hacks required.
>> Another thing is the <head/> tag. What is the reason for this? It
>> doesn't seem to have any functionality.
> I thought that it could keep the meta-information of the icondef
> together, just to have a more clear view. If I eg. would edit an
> icondef.xml, I could just collapse the <head>-tag to focus on only the
> icons. Otherwise I would have to collapse the meta-information one by
> one. I also know that it isn't that important for such a small
> icondef.xml, it's more like a "principle".
Oh come on, this is ridiculous! We should never change the standard to
fit our tools.
This has been said before:
>> In the example you've added an <url/> tag. What is this supposed to
>> hold? (The address of the JEP?)
> Sorry, I know I've used a confusing example, I thought more of the
> address where the .jisp is located (so that people can look for more
> .jisps of the same author or a new version of the same .jisp).
This information is already in the <description/> tag.
>> Why is the name of the author now in a name attribute instead of as
>> the element's data?
> I thought that it would be more clear if in a later version of this
> JEP other things would be required. Eg. if a JID would have to be
> added, it would be just <author name="John Doe"
> jid="john.doe at jabber.org" />. Of course, <author
> jid="john.doe at jabber.org>John Doe</author> would be possible too. I
> personally like the first one more, but that's only a little bit more
> "like" than the other possibility.
Aha, this is a good suggestion, the jid attribute for the <author/> tag.
But for backwards compatibility's sake, keep the name as the data.
It's not like we're going to store the entire vCard in there.
Something like <author jid="john at doe.net">John Doe</author> is very good.
>> Please not that the <text/> tags in your example all have the
>> xml:lang attribute set. This leads to problems. There _must_ be
>> atleast one default string. Adam Theo just didn't find a way to
>> specify this in the schema.
> Sorry, but I can't see why there must be a default string, because
> that's user specific and not JEP038 specific. I think that the client
> will just ask the users (there could be more than one user, using the
> same icondef.xml!) what language they prefer and then store this in in
> their profile (and not in the icondef.xml, because this could bring
> conflicts between 2 users).
Here's how RhymBox does it:
1. A normal <message/> is sent, including the xml:lang attrtibute.
Defined in http://www.jabber.org/jeps/jep-0026.html
2. Recipient uses the xml:lang from the message to build a list of which
<text/> tags it should look for in the body of the <message/>.
(Actually RhymBox simplifies the language to the first identifier. For
example "en-US" becomes "en" ... this is not 100% correct but the
results are better.)
The problem is that if an <icon/> contains no default <text/> and no
<text/> with xml:lang set to the language of the sender's locale, then
there is no way for the recipient to use that <icon/>
Blah, this is a bit akward to explain, but the problem exists when two
people are not using the same language to communicate.
More information about the Standards