On 2013-11-04 21:55, Peter Waher wrote: > Hello all > > > > I have some suggested additions to the XHTML-IM extension XEP-0071 > (which is still in Draft). [..] > > Tables are explicitly forbidden in the current version for the following > reasons [..]
Forbidden seems a particularly strong interpretation. To be clear, the specification says: > Any other elements and attributes defined in the XHTML 1.0 modules that are included in the XHTML-IM Integration Set SHOULD NOT be generated by a compliant implementation, and SHOULD be ignored if received [..] Specialized application could implement support for tables if they want. However, … > 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. … while I'm sympathetic to the argument of machine-to-human interaction, I question the claim to tabular information needing to be returned *often*. Ivan's suggestion of having a separate XEP for representing tabular data, similar to Data Forms, is interesting. So far nobody has expressed a need for that, though. Also, this is the first requirement of XHTML-IM: > 1. IM clients are not XHTML clients: their primary purpose is not to read pre-existing XHTML documents, but to read and generate relatively large numbers of fairly small instant messages. While not stated explicitly, this mostly assumes human-to-human interaction as the /primary/ use case. Partly playing devil's advocate, my arguments counter your proposal are: 1) Current implementations already have a hard time correctly implementing a limited subset of XHTML and seeminly just throw whatever they get in at an HTML rendering widget. At the Summit two weeks ago we had a great presentation on this, highlighting the security risks involved with not whitelisting (as opposed to blacklisting) elements, attribute names, values and CSS constructs. Your example of PSI supporting tables may be a bug :-/ 2) Allowing tables in this context opens another door to lenghty stanzas. As you mentioned in the context of images, large stanzas effectively block a connection for other stanzas. 3) I don't think I have ever felt the need for including tabular information directly in e-mails, let alone IM exchanges. I'd probably refer to an external document instead. > 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. If we were to add support for this, I'd suggest using the Basic Tables Module as defined in [1], possibly restricted further by excluding most attributes. > 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 I disagree strongly with changing this. Also, again, it is not forbidden to support this. > 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. SI File Transfer (XEP-0096) defines XMPP URI support for retrieving files by name [1]. We could define something similar for Jingle File Transfer. > 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. As stated before, I am not convinced of the usefulness of layering HTTP on top of XMPP in general, and the proposed new URI scheme in particular. I think Tomasz Sterna expressed this well [2]. [1] <http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#sec_5.6.> [2] <http://mail.jabber.org/pipermail/standards/2013-July/027796.html> -- ralphm
