[standards-jig] JEP0038 (the emoticon spec) Some suggestions
mattias.campe at rug.ac.be
Wed Sep 25 13:46:20 UTC 2002
Sebastiaan 'CBAS' Deckers wrote:
> 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
Sorry, but the only thing you seemed to like was the category attribute,
which was the only thing that was backward compatible with JEP038 as
it is now, that's why I thought like that.
"No value?", I personally find it more straightforwarded and clear. Also
Richard Dobson said: "Looks good to me, the use of the object tag should
simpify things, and make it more extensible."
>>> 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,...
Of course, but there will be developers who will know xml:lang, but like
I've said before, there won't be any developers who know what just lang
means, if they don't read the XML schema...
>... and it is never a
> good idea to implement something without reading the full spec.
Of course, but then it's better to use a standard and not sth. that you
have to define yourself.
> For example in XHTML 1.0, there is both the lang attribute and the xml:lang
That's to have backward compatibility I think (just like you can use
<object> instead of <img>), in this JEP, we can do it right the right
way, because it's still experimental.
> 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.)
Sorry, but I don't understand "holds the same value?", "same default
value" and "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.
With <object> it will be straightforwarded, with <x/> it is a hack
(that's my view on it). And you didn't answer my question, namely why
did the w3c started using <object> instead of just sticking with
defining <img> <bgsound>...?
>>> 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:
Is that hierararchy really going about some sort of head tag? I can't
really think this has anything to do with supporting a head tag yes or
no. The <head>-tag serves to hold all the meta-information together. If
there wouldn't be a <head>-tag in html, then you could also find the
link to the stylesheet in the middle of the document (?).
For the moment there is no data in the head element that really has to
be found in the beginning of icondef.xml, but maybe in a future version
this will happen and then it will be easy to have it in a <head>-tag.
>>> 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.
Is it? I thought the description tag is to say what you want to achieve
with your icondef.xml. Eg. "Black emoticons for those really hard heavy
metal guys. It has lots and lots of blood, die die die!" (To be clear:
I'm not one of those metal guys ;) )
>>> 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.
okay, no problem for me, to have it like <author jid="john at doe.net">John
Doe</author>. But don't think to much about backward compatibility, this
JEP is still experimental and I have the feeling that you think to much
about that "backward compatibility" (like I see really no reason why
xml:lang couldn't be used, although it breakes compatibility with the
>>> 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
> 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/>
Sorry, but I still don't understand this default thing :(. Wouldn't it
be better to see what kind of language the client is using and just
sending the text string corresponding to that language? There are
thousands of languages and you can't send them all, when I just want to
send ::beer:: to you? If I would build a client, I would look for the
language the receiver is using and if that would be dutch, I would just
let my client send ::bier:: to the other side instead of all the other
> Blah, this is a bit akward to explain, but the problem exists when two
> people are not using the same language to communicate.
> Sebastiaan Deckers
More information about the Standards