[Standards] Suggestions for updates to XEP-0071: XHTML-IM

Peter Waher Peter.Waher at clayster.com
Tue Nov 5 12:53:42 UTC 2013


Hello Ivan.

Thanks for your response and all your suggestions. Some comments on what you wrote:

> I am all for permitting table support long term, but not requiring (or even encouraging it).

That’s the idea. Permitting it. And also recommend clients showing XHTML to either support a basic subset of tables or have a working fall-back mechanism so that content in the tables at least are visible.

> I would however not explicitly require support for tables, as that would imply no IM client could be considered properly compatible with the XEP-0071 without support for rendering HTML tables.

What could be required is to support the markup (and not reject the XHTML as a whole), and either be able to render a small subset or use a valid fallback mechanism (as that explained in Example 8 in the extension).

> Perhaps a separate XEP could define support for HTML tables? Or a client could render replacement as strings?

The idea was to avoid a separate XEP just for adding a detail to a XEP that already exists.

> Proper support for tables could be... complex, especially if a client was not using an existing HTML engine. Consider the very realistic option of using something like Core Text on Apple platforms to draw chat lines.

This is true. This is why a drastically reduced set is sufficient. Most elements in XEP-0071 are reduced. Just think about what attributes are supported, and how the style attribute has been reduced. From my original mail (which is overly simplified, but explains the general idea):

“The most basic would be support for <table>, <tr> and <td>, perhaps also with <th>. If colspan and rowspan attributes are seen as difficult to implement, they could be omitted. The important aspect here is to be able to output textual information in columns. The text-align attribute would be a bonus, but not required.”

> Maybe the tables should be transferred not using XHTML-IM inside <html/> along with other entries, but using a separate entity directly inside <message/>. How about defining them using a separate XEP? This would allow easy and somewhat formatted transfer of pure data (the intended use for tables) while letting the tables be displayed alternately, similar to data forms. If I can use an NSTableView in place of custom drawing for tables, and if I know that table cells containg only simple oneliners or only simple images, possibly displaying tables in a popup, then adding support for tables on a client becomes very easy.

Wouldn’t that be more work? And less flexible? Say you want to use different colors of text, or use bold, italics, etc. Or images?

However, if it is impossible to send tables using XHTML, and there is no support in extending XEP-0071 with tabular data, are there interested parties in creating a separate XEP for sending tabular data as part of messages? I can write such a XEP, as long as there are chat client developers interested in implementing it.

> Requiring support for tables in XEP-0071 may mean that a smaller number of clients is compliant with XEP-0071.

Depends on how you make the extension. I’m sure many clients supporting XHTML-IM already accepts the markup and has a fallback mechanism to display the text. That would still be sufficient to be XEP-0071 compliant.

But using tables would not be prohibited, and applications requiring tables would recommend the use of clients having better support for tables. This would create the necessary motivation for client developers to add table support.

Having mentioned that tables are suitable for human-to-machine chat applications, it can be envisioned to be used in human-to-human chat as well: Say you want to copy content from a spread sheet and send it to a friend (without having to go through saving the content to a file, and transferring the entire file), it would certainly help if the tabular data pasted into the client was sent as a table. The receiving end could select the table, copy it and paste it in his/her spread sheet in turn.

Best regards,
Peter Waher


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131105/bc9a0f92/attachment.html>


More information about the Standards mailing list