On Fri, Dec 13, 2013 at 2:39 PM, Peter Waher <[email protected]>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: > > http://twitpic.com/djrq2a/full > > > > And avoid problems with tabulations inherent in normal text: > > http://twitpic.com/djmor4/full > > > That latter is particularly bad because it's been sent as multiple messages, mind. 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. Dave.
