[Standards] Request for Comments: XEP: Tables in Instant Messaging

Dave Cridland dave at cridland.net
Sun Dec 15 09:47:05 UTC 2013


On Fri, Dec 13, 2013 at 8:54 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."
>
>
>
> 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.
>
>
>

Or the data is a generic data set.


>  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.
>
>
>

That's an argument for using XHTML, perhaps, of which more below.

But reasonably, I don't think it would be a vast undertaking to extend data
forms to handle that if needs be.

>
>
> ·         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.)
>
>
>

We can, and do, simply change schemas on Final state documents on occasion.
Whether that's a good thing or not is up for debate, but no amount of
wishful thinking can make our schemas normative - they're there to aid in
illustration of the protocol. It would be nice, one day, to go through them
and clean them up, especially in the Final cases, and perhaps even mark
specific cases as normative one day.

Secondly,in the case of XEP-0004, there are already two extensions to it;
XEP-0122 and XEP-0141.


>   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.
>

I took away a completely different understanding from that discussion.

You can't just add tables to XEP-0071, because it's deployed and doing so
would break compatibility.

You're allowed to break compatibility between two consenting entities,
though.

I assumed the suggestion was "Write a XEP that defines a feature which, in
turn, allows a sender to detect that an entity will accept XHTML-IM with
the XHTML Tables Module used".

In fact:

     If a sender wishes to send a XHTML-IM [XEP-0071] body which includes
markup using the XHTML Tables Module [Reference here], the sender MUST
first examine the disco response [XEP-0030] (optionally via Entity
Capabilities [XEP-0115]) for the feature "urn:xmpp:tmp:xhtml:tables"

That's pretty much it; the rest is boilerplate.

>    ·         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.
>

Seriously; file transfer,

>    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.
>

s/bad/ugly/ - and I agree, it's orthogonal to the point being made, it just
happens to make it look worse.


>
>
> 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.
>
>
>

Yes, and I'm concerned that an ever increasing portion of the IoT work
seems to have decided to reinvent the technology base it's building upon,
which is a real shame. Worse, judging by this instance, its doing so not
out of an actual requirement, but due to misunderstanding how the existing
extensions can be used.

I'm fine accepting that something better than XEP-0004 or XEP-0050 can be
created, but I'd want to be leveraging the deployed base, most especially
of XEP-0004, rather than ignoring it.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131215/8ef9f41f/attachment.html>


More information about the Standards mailing list