[standards-jig] JEP0038 (the emoticon spec) Some suggestions
mattias.campe at rug.ac.be
Tue Sep 24 20:24:28 CDT 2002
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"...
Sebastiaan 'CBAS' Deckers wrote:
> Mattias Campe wrote:
>> - I've used <text xml:lang="en" alt="cat"> instead of just
>> <text lang="en" alt="cat"> because xml:lang seems to be a standard
>> within xml. This xml:lang is constrained of using a two-letter
>> ISO 639 language code or a two-letter ISO 639 language followed by a
>> three-letter ISO 3166 country code or ... (If people would like this
>> idea I'll add a clear explanation on the Wiki site of Theo)
> 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.
>> - <object> is a html tag which can be used for multimedia purposes and
>> could be used to replace <img>. Because this <object> is more
>> straightforwarded, I would like to use it in this JEP as well.
> 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
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>...
It could be that I don't understand "format" very well, but I don't
understand why there should be a seperate format tag, as this would
require again some internationalisation (xml:lang). So I thought to have
"format" as an attribute of the icon, and that style will be applied to
the "alt" attribute that the user chooses.
>> - the other suggestions can be found at the end of
> Amongst the changes you propose are categories. This seems like a nice
> idea, allthough I can't imagine people would need *that many* emoticons.
> It's an implementation choice I guess.
I agree that it is an implementation choice, that's why I've put it as
attribute and not as tag. I still want to add that a lot of people I
know kick on emoticons. Like I've installed the Jabber client JAJC on a
friends computer and the first thing he noticed was the great support
for emoticons, maybe he even wants more of them? (I installed Rhymbox
too, but he hasn't had time yet to use it ;p)
> 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".
> 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).
> 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.
> 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
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).
> What is the point of a language x-ascii? I don't think it's wise to
> replace one text string with another. Seems like a nop to me.
The language x-ascii could be used for eg. c|_| (beer mug), <>< (fish),
~~~ (sea),... Maybe that you think it's not wise to replace one text
string with another, but I seem to like it and so do the people who have
ideograms as their language, for them is quiet normal to use signs
instead of letters...
More information about the Standards-JIG