[Standards] Request for Comments: XEP: Tables in Instant Messaging
dave at cridland.net
Fri Dec 13 15:21:05 UTC 2013
On Fri, Dec 13, 2013 at 2:39 PM, Peter Waher <Peter.Waher at clayster.com>wrote:
> · It’s a result to a query, not a chat message. So it’s not
> clear for a client how to present it in a chat session.
I don't think XEP-0004 is explicitly restricted to IQ payloads. It
explicitly mentions message threads and "The form-processing entity is
returning data (e.g., search results) to the form-submitting entity, or the
data is a generic data set."
> · It relates to a previous data form, defining fields and values.
> The natural response to such a message is to display the table in a
> separate (search) results window.
Again, I'm not sure it does. In any case, wrapping up the XEP-0004 element
into a suitable wrapper element could work here.
> · It only contains data, not formatting important when
> presenting tables (alignments, and simple styles like fonts, colors, etc.)
To be fair, I'm not entirely convinced it should, but that aside, if
presentation style is important, you also have options to either add that
styling information to XEP-0004 via an extension, or just have disco
negotiation for XHTML Tables in XHTML-IM. Either is less specification cost
than this, and higher flexibility.
Adding it to XEP-0004 has my preference, because that would allow benefit
to all existing protocols currently providing forms. (Example: A MUC
service could highlight dangerous options in red). However, Table support
in XHTML-IM would be fine too, and might cover your use-case better.
> · It does not allow for segmentation, i.e. breaking up into
> several messages.
I'm not convinced sending more than 10k of tabulated data over XMPP is
quite the right choice, actually. I'm pretty sure that if your intent is to
send significantly more than that, then fragmentation and reassembley is
less desirable than send-or-fail.
> The goal is to be able to do something like this:
> And avoid problems with tabulations inherent in normal text:
That latter is particularly bad because it's been sent as multiple
I'd note that in general, you appear to be trying to implement a chat-based
variant of XEP-0050; I'm concerned that this fails the "gap in the
protocol" requirement at this stage.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards