Re: [Standards] IMML
I just thought, we could do something along the lines of Microformats, e.g: Hello, span rel=emoticon title=:-):D/span. Where 'rel' signifies that it is an emoticon and 'title' is the parent of the emoticon (the fall-back). Seems to work pretty well and I don't think it will break existing clients... Michal 'vorner' Vaner wrote: Hello On Mon, Sep 03, 2007 at 05:32:34PM +0200, Jonathan Chayce Dickinson wrote: 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... joke Would you be so kind and plug-n-playd me one in mcabber, please? ;-) /joke 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*. Sure, I know. It is. Bugs are everywhere :-(. But, as you noticed, you probably need a home-grown XML syntethyzer, since you are not allowed to put many other things into the XML stream (like processing instructions). And you need at last to modify that one to handle attributes in different namespace than their tag. They need to generate and place XML namespace prefixes there, remember them, atc. As I said, your way is 100% valid and correct. But I just think the way with separate tag will cause in less effort implementing it. Is there any advantage in your way? If there is, I have no objections using it. -- jonathan chayce dickinson ruby/c# developer cell: +27741863698 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] some profound piece of wisdom smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IMML
Le lundi 10 septembre 2007, Tomasz Sterna a écrit : It was brought on a list but I will repeat it: It WILL break existing client. HTML-like way of thinking will not work here because message stanza is not HTML. Let me rewrite your example (skipping the attributes and adding newlines and whitespace for readability): message bodyHello, span:D/span . /body /message There is no element span/ in the message/body schema, so unknown sub-element 'span' will be ignored by the client (or the whole message, by the more strict ones), leaving us with bodyHello, ./body CDATA. Of course there is an element span/ It's even specified in the XEP-0071 Now, there is no 'rel' attribute. But what does implementation with unknown attribute? They probably ignore them. The 'class' attribute can be used instead We could define some predefined imll-* class bodyHello span class=imml-emoticon:-D/span. /body Personally i don't see the interest of the parent emoticon. What garrent the parent emoticon actually exist. Emoticon that doesn't exist should be rendered as text. The text of an emoticon should have enough meaning by itself. The image is just a plus. If the image has a meaning by itself, maybe inband image should be used instead. signature.asc Description: This is a digitally signed message part.
[Standards] IMML
Hey,
The IMML thread seems to have gone dead.
How about the following:
html [...]
body [...] xmlns:imml=org:alexj:imml
That was fun! imml:icon parent=:-):D/imml:icon. Thanks for the
good time imml:iconbeer/imml:icon.
/body
/html
The above would allow programs to correctly display an emoticon even if
they don't have that one in their 'dictionary'. For example, let's
assume the program doesn't have the : D icon, that would then be
translated into : - ). In the case of the beer emoticon, if it doesn't
have it, it could write it in special formatting. I could even see a
'slick' client doing something like what I have attached. In any case
these are /just/ emoticons, so I don't think all this effort isn't
entirely necessary, but hey, it does make it all rather cool. A lot of
people go for chat clients because of the 'cool' factor.
You would need a fixed set of 'parent' emoticons, that ALL clients
should support.
And as for pasting something out of your source code, you really don't
want the client putting emoticons in it once it gets to the other side
(currently, there is no defined behaviour for that, they can put them
into text or html, as they see fit, AFAIK). Maybe a preserve attribute
is needed on the 'stream/message/body' element, so that the client knows
not to emoticonise text, if this whole IMML thing doesn't pan out. E.g.
message [...]
body preserve=true
(SomeClassInAStrangeProgrammingLanguage:
{SomeMethod:
Console:P(The console print method.);
:}
:)
/body
/message
That would have more than 1 emoticon. I can't think of any programming
languages it would affect, but in the world of the internet, I could bet
you that one exists that would mess up in an IM client.
Can we reach consensus on this? I agree with psa, +1, even as it stands.
Regards,
Jonathan Dickinson
--
jonathan chayce dickinson
ruby/c# developer
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
some profound piece of wisdom
inline: Flowers.png
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] IMML
Hello On Mon, Sep 03, 2007 at 04:42:39PM +0200, Michal 'vorner' Vaner wrote: different language and you can not do that without namespace prefixes. Sorry, not language. Namespace… -- Work with computer has 2 phases. First, computer waits for the user to tell it what to do, then the user waits for the computer to do it. Therefore, computer work consists mostly of waiting. Michal 'vorner' Vaner pgp3d6zlanD5X.pgp Description: PGP signature
Re: [Standards] IMML
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:
Hello
On Mon, Sep 03, 2007 at 04:18:29PM +0200, Jonathan Chayce Dickinson wrote:
message [...]
body preserve=true
(SomeClassInAStrangeProgrammingLanguage:
{SomeMethod:
Console:P(The console print method.);
:}
:)
/body
/message
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'/
body
…
/body
/message
(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
ruby/c# developer
email: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
some profound piece of wisdom
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Standards] IMML
Along those lines, the preserve tag should maybe have the following modes: * text - don't do something like emoticons or automatic spelling correction * whitespace - don't remove whitespace * all - preserve both text and whitespace. * none - do what you see fit to the text (default). Michal 'vorner' Vaner wrote: Hello On Mon, Sep 03, 2007 at 04:42:39PM +0200, Michal 'vorner' Vaner wrote: different language and you can not do that without namespace prefixes. Sorry, not language. Namespace… -- jonathan chayce dickinson ruby/c# developer cell: +27741863698 email: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] some profound piece of wisdom smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IMML
Hello On Mon, Sep 03, 2007 at 05:32:34PM +0200, Jonathan Chayce Dickinson wrote: 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... joke Would you be so kind and plug-n-playd me one in mcabber, please? ;-) /joke 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*. Sure, I know. It is. Bugs are everywhere :-(. But, as you noticed, you probably need a home-grown XML syntethyzer, since you are not allowed to put many other things into the XML stream (like processing instructions). And you need at last to modify that one to handle attributes in different namespace than their tag. They need to generate and place XML namespace prefixes there, remember them, atc. As I said, your way is 100% valid and correct. But I just think the way with separate tag will cause in less effort implementing it. Is there any advantage in your way? If there is, I have no objections using it. -- When all else fails, EAT!!! Michal 'vorner' Vaner pgp0CCjJXoUC9.pgp Description: PGP signature
Re: [Standards] IMML
On Wednesday 08 August 2007 08:01, Alex Jones wrote: On Tue, 2007-08-07 at 23:08 +0200, Tomasz Sterna wrote: Dnia 07-08-2007, wto o godzinie 21:45 +0100, Alex Jones napisał(a): And this is exactly the problem. rsync -a /foo/ /bar/ find -name *foo* Correct way of rendering these is to apply italic and bold, but do NOT remove the slashes and asterisks. Where is this specification? I think he was talking about commonsense in that particular instance. Then again, another way to do it is render them hidden. It looks mangled but when you copy the text they will still go into the clipboard (at least that's the experience I get with using Firefox and copying rp elements which are typically hidden) so it won't destroy the code. Daniel pgpMrrMxg6q4N.pgp Description: PGP signature
Re: [Standards] IMML
Dnia 14-08-2007, wto o godzinie 18:45 +1000, Daniel Noll napisał(a): Then again, another way to do it is render them hidden. It looks mangled but when you copy the text they will still go into the clipboard It would make the parts when the attribute was applied unnecessary (code parts, paths) look wrong. Italics on /parts/of/file/paths do not make it unreadable, but removing slashes do. -- Tomasz Sterna Xiaoka.com http://www.xiaoka.com/
Re: [Standards] IMML
On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote: Alex Jones wrote: This isn't about formatting, this is about getting rid of the guesswork. Similar problems arise in parsing out icons in the presence of things like regular expressions. Or maybe even regular chat: Count the screws (there should be 8) Incorrectly gets parsed out as Count the screws (there should be SMILEYFACECOOL I agree that we need to address this - since it is a relatively common frustration for users. Mridul Muralidharan wrote: If we just add another tag to explicitly mark emoticons - and remove the implicit rendering completely - then Alex's baseline requirements should be done with IM-XHTML itself ? Yes. This would be backward compatible too since, IIRC, XHTML parsers should ignore tags they don't understand (and the tag would be qualified by a namespace other than 'http://www.w3.org/1999/xhtml' anyway). - Ian I feel it shouldn't be a part of XHTML-IM though. I think there is a need to use icons that is independent of the need to use even the most minimal, valid support of XHTML-IM.
Re: [Standards] IMML
On Wed, 2007-08-08 at 16:02 +0200, Michal 'vorner' Vaner wrote: Hello On Wed, Aug 08, 2007 at 01:28:53PM +0100, Alex Jones wrote: Mridul Muralidharan wrote: If we just add another tag to explicitly mark emoticons - and remove the implicit rendering completely - then Alex's baseline requirements should be done with IM-XHTML itself ? Yes. This would be backward compatible too since, IIRC, XHTML parsers should ignore tags they don't understand (and the tag would be qualified by a namespace other than 'http://www.w3.org/1999/xhtml' anyway). - Ian I feel it shouldn't be a part of XHTML-IM though. I think there is a need to use icons that is independent of the need to use even the most minimal, valid support of XHTML-IM. I think the XHTML-IM thing is OK. At last better than having the same message 3 times in one stanza. If someone wants to have that smart, then he has XHTML-IM. (Take it as an opinion from someone who does not like message formating, image emoticons and so on at all) I imagine such IMML messages would replace most XHTML messages anyway, meaning only two copies of the message. By the way, how the sending client knows in is an emoticon? Many users I know just type them, not select from list. That's an application issue that can be tackled. In any event, rather the sender decide than the receiver.
Re: [Standards] IMML
Alex Jones wrote: By the way, how the sending client knows in is an emoticon? Many users I know just type them, not select from list. That's an application issue that can be tackled. In any event, rather the sender decide than the receiver. Yes. The sending user will see how her client interpreted what she typed, and can therefore control what the receiving user will see before clicking SEND. Alex Jones wrote: On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote: Mridul Muralidharan wrote: If we just add another tag to explicitly mark emoticons - and remove the implicit rendering completely - then Alex's baseline requirements should be done with IM-XHTML itself ? Yes. This would be backward compatible too since, IIRC, XHTML parsers should ignore tags they don't understand (and the tag would be qualified by a namespace other than 'http://www.w3.org/1999/xhtml' anyway). I feel it shouldn't be a part of XHTML-IM though. I think there is a need to use icons that is independent of the need to use even the most minimal, valid support of XHTML-IM. Well, RFC 3921 states that the body/ element MUST NOT contain mixed content. And I agree with Michal that we should avoid including three copies of the message in each stanza. So it seems that the only place for the new emoticon tags is inside the XHTML-IM (under a different namespace). Furthermore, it would be complicated to write the code to display both XHTML and emoticon elements if they are kept separate. Whereas it is trivial to write the code to ignore the one or the other if they are merged. - Ian
Re: [Standards] IMML
Ian Paterson wrote: Alex Jones wrote: On Wed, 2007-08-08 at 13:21 +0100, Ian Paterson wrote: Mridul Muralidharan wrote: If we just add another tag to explicitly mark emoticons - and remove the implicit rendering completely - then Alex's baseline requirements should be done with IM-XHTML itself ? Yes. This would be backward compatible too since, IIRC, XHTML parsers should ignore tags they don't understand (and the tag would be qualified by a namespace other than 'http://www.w3.org/1999/xhtml' anyway). I feel it shouldn't be a part of XHTML-IM though. I think there is a need to use icons that is independent of the need to use even the most minimal, valid support of XHTML-IM. Well, RFC 3921 states that the body/ element MUST NOT contain mixed content. And I agree with Michal that we should avoid including three copies of the message in each stanza. So it seems that the only place for the new emoticon tags is inside the XHTML-IM (under a different namespace). Furthermore, it would be complicated to write the code to display both XHTML and emoticon elements if they are kept separate. Whereas it is trivial to write the code to ignore the one or the other if they are merged. +1. See also: http://www.xmpp.org/extensions/xep-0071.html#w3c-conformance /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] IMML - attribute tagging
Dnia 07-08-2007, wto o godzinie 10:18 +0200, Michal 'vorner' Vaner napisał(a): But I think emphasis is too much for the protocol. Besides, I would do backwards-compatible protocol (no other element besides xhtml and text, why send third version of the text). Just an idea: message textThis is not a joke ;-) http://notajoke.org/text IMML:emoticon start='20' length='3'/ IMML:url start='24' length='19'/ /message +10 on this attribute tagging approach. My experience with XHTML-IM during implementation for jggtrans is that its both hard to generate (I guess that's why there are so few clients implementing it) and to interpret (especially when you do not have a full blown HTML renderer handy). Attribute based systems are both trivial to generate, interpret and degrade well with systems that do not know it and just skip it (even better than HTML based systems). -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] IMML
On Mon, Aug 06, 2007 at 12:17:39PM -0700, Rachel Blackman wrote: XHTML-IM is for sending HTML messages. IMML is for sending modern Instant Messages. IMML intentionally leaves out most of the flexibility that XHTML-IM provides, most of which has no semantic meaning whatsoever. We might as well be using XSL-FO. Imposing rules such as you suggest for HTML a's just adds to the complexity of implementation, and illustrates that HTML in any form is simply the wrong tool for the job. This is an argument that will never be resolved. We have people who want to be able to put every single HTML object (including Java, Active X, DHTML and so on) into messages and feel XHTML-IM is far too restrictive and anemic; they argue you should be able to paste HTML in from Firefox and have it display exactly as it was. Then every XMPP client would have to embed the firefox rendering engine for that. Displaying HTML (mostly any kind, XHTML, HTML 4...) in different browsers will lead to different results (in the real world). Maybe they should post screenshots instead :-) ? And then we have people who feel XHTML-IM is too complex and is overkill for the situation. XHTML-IM manages to strike a (somewhat sensible) middle ground, which is probably why it will stick around. :) There is one big difference between XHTML-IM and IMML, which are simply a matter of semantic. XHTML-IM says how to exactly display a text, what color, what size, what padding, where to place an image, or whatever. IMML just says display this with emphasis, and this is an URL, display it approriate. Clients can then choose how to put emphasis on some text (eg. by rendering it bold). XHTML-IM doesn't leave such a choice, either the client can render something bold or he has no way to display a bold element. I also disable XHTML-IM always, because the people seem to never get it right to send just normal text. Often their text is smaller than mine and some even think it's funny or very readable to have some big and colorful text. While I agree that lots of todays youth just loves these gimmicks and that it might be important to support colors and images and all that, I also want to have a middle way between XHTML-IM and no formatting at all. IMML is seems to be restricted enough to provide a reliable way to display an instant message while not enforcing how something might be displayed. For XHTML-IM one must roll a more or less complete XHTML-IM parser and CSS1 parser. I agree that it is not impossible to implement it due to the very limited set of XHTML and CSS1. But XHTML-IM leaves the destination client almost no freedom in displaying the text. A console client will have no other choice than just ignoring the XHTML-IM content of a message or run some heuristics over the html and somehow find out what color or attributes a text might have. IMML is way easier to implement, and clients and users still have choice how to display something with emphasis. IMML moves the choice to the receiving end, XHTML-IM leaves the choice to the sender. It's mostly a semantic difference. And afterall, instant messages are usually not documents. Just my 2 cents. R
Re: [Standards] IMML
Hello I'm for the marking of URL or emoticon (not that they would bother me any more, I disabled emoticons completely and have just text, and urls at last don't screw the message up). But I think emphasis is too much for the protocol. Besides, I would do backwards-compatible protocol (no other element besides xhtml and text, why send third version of the text). Just an idea: message textThis is not a joke ;-) http://notajoke.org/text IMML:emoticon start='20' length='3'/ IMML:url start='24' length='19'/ /message -- This is a terroristic email. It will explode in 10 minutes, if you do not close it in the meantime. Michal 'vorner' Vaner pgpTvfEoCIiiT.pgp Description: PGP signature
Re: [Standards] IMML
Hi Michal On Tue, 2007-08-07 at 10:18 +0200, Michal 'vorner' Vaner wrote: Hello I'm for the marking of URL or emoticon (not that they would bother me any more, I disabled emoticons completely and have just text, and urls at last don't screw the message up). But I think emphasis is too much for the protocol Personally, I sometimes find that plain text alone is not enough to communicate effectively with people, especially when complicated concepts like sarcasm are involved. Newspapers and typeset books generally get away with using emphasis (usually in the form of italicised text) without bringing in background colours and varying typefaces. I remain fairly convinced that some kind of emphasis is part of everyday natural speech. This is my justification for the inclusion. Besides, I would do backwards-compatible protocol (no other element besides xhtml and text, why send third version of the text). Just an idea: message textThis is not a joke ;-) http://notajoke.org/text IMML:emoticon start='20' length='3'/ IMML:url start='24' length='19'/ /message This isn't a very XML-way of doing this. Consider this IMML message instead: message textThis is imml:emnot/imml:em a joke imml:icon;-)/imml:icon imml:urihttp://notajoke.org/imml:uri /message The beauty of this is that (specification permitting) if the client wishes to ignore the IMML markup and process the message as a traditional plain text message, it can. The message IS backwards compatible! This is exactly the way HTML works with respect to unknown elements. We can do this while XHTML-IM can't because of things like the HTML a element relegating the actual URI to element attribute data - the child data under an a is the hyperlink text, not the URI.
Re: [Standards] IMML
Hi Alex! Alex Jones schrieb: message textThis is imml:emnot/imml:em a joke imml:icon;-)/imml:icon imml:urihttp://notajoke.org/imml:uri /message The beauty of this is that (specification permitting) if the client wishes to ignore the IMML markup and process the message as a traditional plain text message, it can. The message IS backwards compatible! This is exactly the way HTML works with respect to unknown elements. In HTML this behaviour is defined, but XML is not HTML. You should not expect the Jabber clients to ignore these extra tags. They typically do parse the stanza and create some sort of a DOM like tree out of it. Depending on how they implemented it, I expect you will get displayed most of the time something out of that: - This is - a joke - This is a joke - Matthias
Re: [Standards] IMML
On 8/7/07, Alex Jones [EMAIL PROTECTED] wrote: message textThis is imml:emnot/imml:em a joke imml:icon;-)/imml:icon imml:urihttp://notajoke.org/imml:uri /message The message IS backwards compatible! offtopicIt is not, since no body/ tag is included. It will be when stanza looks like: message bodyThis is *not* a joke ;-)/body textThis is imml:emnot/imml:em a joke imml:icon;-)/imml:icon imml:urihttp://notajoke.org/imml:uri /message Or something like this./offtopic - made by Tomasz Sieprawski aka DeSnajpa_V www https://mastahizm.pl xmpp [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] xmpp [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] mail [EMAIL PROTECTED] mail:[EMAIL PROTECTED] xmpp:[EMAIL PROTECTED]
Re: [Standards] IMML
Le mardi 7 août 2007, Alex Jones a écrit : On Tue, 2007-08-07 at 14:12 +0200, Matthias Wimmer wrote: Hi Alex! Alex Jones schrieb: message textThis is imml:emnot/imml:em a joke imml:icon;-)/imml:icon imml:urihttp://notajoke.org/imml:uri /message What about this: ? bodyThis is *not* a joke ;-) lt;http://notajoke.orggt; /body And client could interpret *bold* /italic/ or _underline_ (even the average human could do that if the client doesn't support it) a kind of simplified wiki syntax. Maybe that could be recommended somewhere. signature.asc Description: This is a digitally signed message part.
Re: [Standards] IMML
Hello On Tue, Aug 07, 2007 at 12:57:53PM +0100, Alex Jones wrote: Personally, I sometimes find that plain text alone is not enough to communicate effectively with people, especially when complicated concepts like sarcasm are involved. Newspapers and typeset books generally get away with using emphasis (usually in the form of italicised text) without bringing in background colours and varying typefaces. I remain fairly convinced that some kind of emphasis is part of everyday natural speech. This is my justification for the inclusion. I really _do_ thing text is enough ;-). -- No, you will not fix me Computer Michal 'vorner' Vaner pgpjMw4CW6fwh.pgp Description: PGP signature
Re: [Standards] IMML
On Tue, 2007-08-07 at 13:23 -0600, Peter Saint-Andre wrote: IMHO that would be a good item to add to the security considerations in XEP-0071. I think XHTML-IM pretty much does what IMML does, but in a W3C-friendly manner. If people want to support an even more reduced subset of XHTML then I have no objections. I think clients can effectively do that via XEP-0071. The baseline requirements are pretty minimal: http://www.xmpp.org/extensions/xep-0071.html#profile-summary If people want something even more minimal and texty, they could simply use Textile or some other lightweight text formatting approach: http://en.wikipedia.org/wiki/Comparison_of_lightweight_markup_languages It seems that lots of Jabber clients already support things like *bold* and /italic/ and _underline_ so perhaps that is enough... And this is exactly the problem. rsync -a /foo/ /bar/ find -name *foo* Both legitimate uses for * and / that will end up being mangled on the other side. This isn't about formatting, this is about getting rid of the guesswork. Similar problems arise in parsing out icons in the presence of things like regular expressions. Or maybe even regular chat: Count the screws (there should be 8) Incorrectly gets parsed out as Count the screws (there should be SMILEYFACECOOL Without any knowledge on the sender's half. I don't see how XHTML-IM can support icon delimitation like IMML. I really don't think we are talking about a subset of XHTML-IM. -- Alex Jones [EMAIL PROTECTED]
Re: [Standards] IMML
Dnia 07-08-2007, wto o godzinie 21:45 +0100, Alex Jones napisał(a): And this is exactly the problem. rsync -a /foo/ /bar/ find -name *foo* Correct way of rendering these is to apply italic and bold, but do NOT remove the slashes and asterisks. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] IMML
On Tue, 2007-08-07 at 23:08 +0200, Tomasz Sterna wrote: Dnia 07-08-2007, wto o godzinie 21:45 +0100, Alex Jones napisał(a): And this is exactly the problem. rsync -a /foo/ /bar/ find -name *foo* Correct way of rendering these is to apply italic and bold, but do NOT remove the slashes and asterisks. Where is this specification?
Re: [Standards] IMML
Top-posting discouraged, comments at the bottom. On Wed, Aug 08, 2007 at 12:04:25AM +0100, Alex Jones wrote: On Tue, 2007-08-07 at 14:56 -0600, Peter Saint-Andre wrote: Alex Jones wrote: I don't see how XHTML-IM can support icon delimitation like IMML. I really don't think we are talking about a subset of XHTML-IM. Emoticons are an entirely separate problem. Feel free to update XEP-0038 or convince others to do so: http://www.xmpp.org/extensions/xep-0038.html From XEP 38: * The client sends the message with the text string to the intended recipient. * The recipient client receives the message with the text string. IMML complements XEP 38. The text strings are explicitly delimited in IMML icon elements, rather than just fumbled into the message with the hope that it is correctly parsed out again on the other side. Yet XEP-0038 says: *** The text strings representing the icons will be sent like any other text (this document doesn't require extra tags or attributes in the messages being sent). *** Furthermore there are the concerns raised by pgmillard way back in 2003: I still have serious issues w/ -38. My primary concern is that it's impossible to implement this JEP and still have a client be able to handle 50K message bodies. I'd like to see this JEP turn into something which just defines _STANDARD_ emtoticons for jabber, and be done with it. http://mail.jabber.org/pipermail/standards/2003-April/002995.html Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml
[Standards] IMML
Hi list I am intending to make an XEP of this. Is anyone interested in helping me, as I haven't really got a clue how to write a proper specification. http://spark.us.weej.net/~alex/temp/imml.html Thanks! -- Alex Jones [EMAIL PROTECTED]
Re: [Standards] IMML
On Sunday 05 August 2007 5:11 pm, Alex Jones wrote: Hi list I am intending to make an XEP of this. Is anyone interested in helping me, as I haven't really got a clue how to write a proper specification. http://spark.us.weej.net/~alex/temp/imml.html Thanks! XEP-71 (XHTML-IM), offers a subset of XHTML markup suitable for IM. This should be sufficient, don't you think? -Justin
