jdev - 2022-07-17

I decided to take another stab at implementing multi-item results on XEP-0004: Data Forms, but as usual I'm still confused. The spec makes it look like items and repoted can exist alongside field, title, etc. but what does it even mean to have a normal form that also contains reported/items? Is this correct that a form can have both normal fields and the multi-item stuff?

The spec does not forbid it, so it is allowed. Glob help us all.

The schema seems to suggest it's allowed (though as usual, I don't know XML schema and may be mis-reading something), but the meaning of the actual text seems very unclear to me

I guess a better question is "is anyone else doing or allowing this?"

aioxmpp seems to disallow fields being mixed in with items, but it looks like it would allow title/instructions as far as I can see

Someone asked about this recently, either here or xsf@, trying to find it.

Might have been me; I think I tried to do this a couple of months ago but I can't remember what was said

nbxmpp (Gajim) appears to allow title and instructions but disallow fields too; I guess I'll just do this since that's what others are doing (though if anyone has an example of doing something else, I'd love to know)

Although this seems entirely unsupported by the text or schema.

Aha, found https://logs.xmpp.org/xsf/2022-06-07?p=h#2022-06-07-50bc9a07d99ec16a

oh nice, thanks

drat; singpolyma makes a good argument for why both make sense, now I'm not sure what to do.

https://logs.xmpp.org/xsf/2022-06-08?p=h#2022-06-08-7b362a17b6eba8a8 hints at prior art of allowing both (or not disallowing)

I note that Prosody's util.dataforms doesn't do <reported> at all

There's a user search module doing it, but it's constructing the XML itself IIRC

Sam, i never came across a use case where this is needed

and i dont implement stuff that "maybe, in theory someone at someday could need"

especially if it is not described as a clear use case for the xep

and only is possible because nothing forbids it

singpolymas example is a pretty concrete one though (in jmp.chat they want to show the account balance followed by a table of recent transactions)

Sounds like there are already some incompatibilities due to the ambiguity in the spec, so maybe I should just not implement it at all.

you know you cannot have only one dataform in a stanza

That normally means "this form or this other fallback form" in most specs though, not "display both these forms"

(to be clear, it sounded like you were saying "you must have multiple forms", but obviously that's not right, so I'm assuming you meant "it's possible to have multiple forms"?)

yes its possible, depends on where you use that

Sure, so now if I include a normal form and a multi-item form we have an ambiguity about what that means that may depend on context, so I dunno if that approach is better

are we talking about adhoc results?

Could be anything, this is just a generic library for building forms to be embedded in other things (ad-hoc is one of the things that already uses it)

funny, the adhoc spec misses the FORM_TYPE in all its dataforms

and i never heard of "fallback" forms

either you support dataforms or not

the adhoc spec does not say anything about multiple forms

I'd have to go look, but I'm pretty sure several specs define having multiple forms in one payload as "if you don't support something in the first form, use the second"

or "show the title and let the user choose between these two forms" or something along thos elines

i think you misremember, you probably mean IBR

which has a Dataform, and if you dont support a dataform, here are custom xep defined fileds as fallback

Could be, but either way it sounds like the meaning of multiple forms is also not well defined or is very context dependent, which still makes it hard to implement data forms cleanly

there is no fallback for "i implemented only half of the dataform xep"

but this would not have anything to do with your lib or?

you just parse a dataform

if its 2, then you parse 2

You don't strictly need FORM_TYPE to render a random form, no?

its client business if he displays 2 or 1

Zash, the problem xmpp should be extensible

if the form does not define that its indeed the form from the xep

i cannot filter the forms for the correct formtype

means, if someone attaches a second form, i dont know which one to choose

its like if you add a new custom node, without namespace

yes its possible , but not really good design

to the use case with the account balance, if someone adds a issue in Gajim requesting that i display multiple forms below each other on adhoc results

i would implement that

thats like 5 minutes of work

Even if we assume this is all a thing we could do that would work for every spec, it's still unclear to me whether multi-item forms should include title/instructions. It makes sense that they would, I just think we need some clarity here

im didnt read the spec for that, but it seems like a nobrainer

like here have a form, but i dont tell you what it is about

does not seems like a good solution

you could argue, its probably in the context of how you requested this clear

I don't disagree, but if we say "no fields, but can have instructions" we're just inventing stuff that the spec definitely doesn't say, so that seems like it will cause incompatibilities and problems.

yes this should be clarified

reading the XEP now though nothing idicates that this is not to be expected

title and instructions are described

and later there is one paragraph, about how a table can be displayed in a form

Right, but if title and instructions are allowed then why wouldn't fields be?

yes, i agree, its not forbidden

But multiple libraries seem to forbid it, so I'm not sure what to do to avoid bad incompatibilities.

it would though then really messy in my opinion

like then the order really matters

like what if reported comes in the middle of the fields etc

like its clear that nobody had this use case in mind

Yah

any sane dev would wrap this in some parent nodes

and separate the forms

I'm not sure that's true

I suppose I need to know what clients are doing in real life. Eg. if most clients would just ignore the second form, now half the data you returned isn't being displayed. Doesn't seem like a good idea in that case.

there is no way clients support this one way or another

its just not a use case until now maybe

and now we can decide which way to go

yah, maybe it's impossible to ensure good compatibility so we should just pick something, fix the XEP (or write a new XEP that clarifies it) and move on

or do nothing, having one use case in decades of usage

its just not supported in xmpp ..

Maybe, but that still leaves me with "I have to implement this, different clients implement it in different ways and I'm not sure which one I should do"

i doubt this, you have one example where a lib parses both, reported and normal fields into one object?

Apparently Smack allows mixing them, but nbxmpp does not. Which is right? The current state of the world is fine only until some dev sends a mixed form from smack to nbxmpp and now they can't figure out why their thing is broken.

smacks allows to parse it mixed?

or smacks allows to create mixed forms?

Apparently; that's what someone said earlier

Both, I think? Let me try to figure it out, one moment

because thats two very different things

Actually, I don't see multi-item forms in Smack at all, so maybe they were wrong

oh wait, there it is, looking again

Yah, looks like it allows both. It parses using the same dataform builder that you'd use to create your own, and it allows adding fields and items

and then how does it make it accessable by the client?

You can call a method to get fields, you can call another method to get items

.......

damn it

:D

Looks like it loses ordering info between the two; they're kept ordered, but separate

yeah i guess then you have to decide :)

of course its not easily doable, you would need to put extra thought into that

but i guess its always, fields first

items later

atleast i cant think of a reason why i would display a Table first in GUI, and afterwards some info

either way its probably not critical here

If I were to support both I think from my APIs perspective I would treat items as if they were just another field that takes multiple values (and the value is other fields).

Items are displayed like columns. If there's a field then more items, then they're just two separate tables with the same header.

if i would implement that, i would make something like dataform.add_table()

table.add_row()

yah, something like that

I'll write up all the possibilities from this discussion and send it to standards@. Maybe then we can come to a consensus and I can write an XEP clarifying this, however it comes out.

i mean if i think about it, and we say, ok that was intended, dataforms support putting both in, its not terrible hard to update the dataform implementations

Email describing some of this sent to standards@, please mention anything I've left out or if you think I've mischaracterized anything.