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

Ivan Vučica ivan at vucica.net
Mon Nov 4 22:10:57 UTC 2013


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

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. Perhaps a separate XEP
could define support for HTML tables? Or a client could render replacement
as strings?

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.

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.

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

Other suggested changes, yes.

On Mon, Nov 4, 2013 at 9:55 PM, Peter Waher <Peter.Waher at clayster.com>wrote:

>  Hello all
>
>
>
> I have some suggested additions to the XHTML-IM extension XEP-0071 (which
> is still in Draft). I would very much like to see these added to the
> existing document. I’ll list them below with comments why I believe these
> are features that merit addition:
> Tables
>
> Tables are explicitly forbidden in the current version for the following
> reasons:
>
>
>
> “… There is little or no foreseeable need for such elements within the
> context of instant messaging.”
>
> “The foregoing is doubly true of more advanced markup such as tables…”
>
>
>
> This sounds like an unnecessary restriction probably stemming from the
> fact that “instant messaging” equates human-to-human chat applications to
> many people. However, XMPP is obviously much more than that.
>
>
>
> There are many examples were the support for tables would actually be very
> beneficent, especially in human-to-machine chat applications, i.e. chatting
> with robots. (Machine-to-machine is obviously solved using XML and not
> text.) A robot often needs to return tabular information, for instance,
> voting results, to take an example that all XSF-members knows.
>
>
>
> Another example can be the following. Using a simple chat client I connect
> to a device and read a sensor. Using only text, I’m forced to output the
> information using semi-tables using tab characters. Result:
>
> http://twitpic.com/djmor4
>
>
>
> Using tables in an XHTML-IM section, provides a better mechanism to output
> tabulated output. The Psi client supports this:
>
> http://twitpic.com/djrq2a
>
>
>
> Support for a basic set of table support is thus warranted in IM-clients.
> 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.
> Data URI scheme
>
>
>
> Rephrasing §7.5, regarding support of data URI scheme in IMG tags. It says
> its use is “not recommended”. However, it could state that use by sender is
> not recommended for the reasons listed (i.e. possible large stanzas), but
> support for the URI scheme in the receiver should still be recommended (but
> not required), if somebody uses it anyway (i.e. it is not forbidden).
>
> http://xmpp.org/extensions/xep-0071.html#profile-image
> HTTPX support
>
> An important aspect of IMG tags is the ability to fetch images from
> anywhere reachable by an URL. However, publishing dynamic content in an
> XHTML layout might be difficult using HTTP-URLs, especially if the sender
> is not reachable from the client (i.e. lies behind a firewall). Optional
> methods for sending images over XMPP exist, but they cannot (?) be combined
> with XHTML and the IMG-tag.
>
>
>
> However, the new extension HTTP over XMPP (XEP-0332) solves this by
> defining a new URI scheme: *httpx*. A reference to XEP-0332 would be in
> order from §7.5 (Image Module Profile) stating that images can be
> transferred using URLs if support for the httpx URI scheme is available by
> both sender and receiver.
>
> http://xmpp.org/extensions/xep-0332.html#httpxscheme
>
>
>
>
>
> Any comments?
>
>
>
> Best regards,
>
> Peter Waher
>
>
>
>
>



-- 
Ivan Vučica
ivan at vucica.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131104/aa4c8420/attachment.html>


More information about the Standards mailing list