[standards-jig] JEP0038 (the emoticon spec) Some suggestions

Mattias Campe mattias.campe at rug.ac.be
Wed Sep 25 01:24:28 UTC 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 
> 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>...

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
>>   http://www.theoretic.com/?IM_Icons/Styles
> 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 
> 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).

> 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 mailing list