Hello Dave Thanks for your input and for taking the time read and respond to it. I'll try to respond to your concerns one at a time:
* 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." Well, it stipulates that the x-data form is: result 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's perhaps semantically difficult to interpret this (which is itself a problem) but I interpret it as it being a response to something. Do you have an example of this being used in something that is not a response to a query? Note also, that XEP-0004 models result sets or data sets, which, for obvious reasons are easy to display as tables. But not all tables can be modelled as data sets. (set of data sets could be seen as a subset of the set of tables). Simplest example can be a table with cells spanning multiple grid elements. Such a table could not be modelled as a data set consisting of records with field values. * 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. Well, you have the concept of field variables, which of course is a reference to the original form, which further underlines my point that the example in XEP-0004 refers to a result from a previous operation concerning a data form. (Which is also natural, since the purpose of XEP-0004 is to define an architecture for data forms.) * 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. Not without breaking the schema. Modifying the schema is impossible as XEP-0004 is final, nor do I think desirable. Breaking the schema is illegal in some cases, for instance using EXI where only allowed operations according to the schema can be streamed, or if you want to use schemas for validation, or quality assurance purposes. Furthermore, it breaks the requirement that messages should validate according to schemas. (Which is done unfortunately in several cases. But to recommend breaking schemas is another matter.) 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. Well, this was my first approach, and it was not received in the way you describe. The general consensus in that thread was the other way around: To have a separate XEP for sending tables. Peter Saint-André, who authored XEP-0071, also preferred this method. * 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. Well, that must be a personal opinion. Of course it's a fail-safe method of solving the problem if somebody pastes a spread sheet that happens to be a little too long. To have two different methods of sending "small" tables compared to sending "larger" sounds less desirable to me than one method with a fail-safe mechanism to handle exceptional cases. 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. Why would this be "bad"? And it's not the point that was being made. 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. Yes and no. It's the ability to use only chat to communicate and send/receive tables by human or machine users. It fills an obvious gap, since tables cannot be sent in chat today. You can invoke other sets of steps to provoke commands that return result sets, but that is not what we try to achieve. And XEP-0050 is not sufficient, even for the particular case we are looking at (to which this proposal is not limited). Some comments on why XEP-0050 is not sufficient (apart from it not being part of a chat conversation between users) is taken from XEP-0326: Ad-Hoc Commands (XEP-0050)<http://xmpp.org/extensions/xep-0050.html> [3<http://xmpp.org/extensions/xep-0326.html#nt-id95839>] defines how ad-hoc commands can be implemented and how clients can use such commands to interact with underlying logic. But XEP-0050 is not used in this specification. There are multiple reasons: · We want to be able to use XEP-0050 for other types of commands, than commands defined in this specification. Generally, XEP-0050 is used to implement system-wide commands. · Commands defined in this specification are context sensitive, i.e. they depend on the type of node and the context of the node on which the act. · It is a requirement to be able to execute commands on sets of nodes directly. · Since commands have to be context sensitive, a large concentrator system may have hundreds or thousands of different commands, making it impossible to create context sensitive GUI's using XEP-0050. · Dialog types used for Ad-Hoc-commands are not sufficient. First, dynamic dialogs are required in the general case. (XEP xep-0000-DynamicForms.html<http://xmpp.org/extensions/xep-0000-DynamicForms.html> define how to create dynamic forms.) Furthermore, the wizard style type of dialogs used for more complex dialogs in ad-hoc commands, are difficult to automate. Still, we've only been talking on request/response mechanisms here, of which both XEP-0004 and XEP-0050 belong, which further underlies my response earlier that XEP-0004 returned data sets in response to a previous query. This proposal is asynchronous and based on messages. One user can copy and paste tabular data and send it, without it being part of a request. The same with contextual chat robots. Best regards, Peter Waher
