SamI 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?
ZashThe spec does not forbid it, so it is allowed. Glob help us all.
SamThe 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
SamI guess a better question is "is anyone else doing or allowing this?"
Samaioxmpp seems to disallow fields being mixed in with items, but it looks like it would allow title/instructions as far as I can see
Anton L. Šijanechas left
ZashSomeone asked about this recently, either here or xsf@, trying to find it.
SamMight have been me; I think I tried to do this a couple of months ago but I can't remember what was said
Samnbxmpp (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)
SamAlthough this seems entirely unsupported by the text or schema.
ZashAha, found https://logs.xmpp.org/xsf/2022-06-07?p=h#2022-06-07-50bc9a07d99ec16a
Samoh nice, thanks
Samdrat; singpolyma makes a good argument for why both make sense, now I'm not sure what to do.
Zashhttps://logs.xmpp.org/xsf/2022-06-08?p=h#2022-06-08-7b362a17b6eba8a8 hints at prior art of allowing both (or not disallowing)
ZashI note that Prosody's util.dataforms doesn't do <reported> at all
ZashThere's a user search module doing it, but it's constructing the XML itself IIRC
lovetoxSam, i never came across a use case where this is needed
lovetoxand i dont implement stuff that "maybe, in theory someone at someday could need"
lovetoxespecially if it is not described as a clear use case for the xep
lovetoxand only is possible because nothing forbids it
Samsingpolymas example is a pretty concrete one though (in jmp.chat they want to show the account balance followed by a table of recent transactions)
SamSounds like there are already some incompatibilities due to the ambiguity in the spec, so maybe I should just not implement it at all.
lovetoxyou know you cannot have only one dataform in a stanza
SamThat normally means "this form or this other fallback form" in most specs though, not "display both these forms"
Sam(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"?)
lovetoxyes its possible, depends on where you use that
SamSure, 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
lovetoxare we talking about adhoc results?
SamCould 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)
lovetoxfunny, the adhoc spec misses the FORM_TYPE in all its dataforms
lovetoxand i never heard of "fallback" forms
lovetoxeither you support dataforms or not
lovetoxthe adhoc spec does not say anything about multiple forms
SamI'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"
Samor "show the title and let the user choose between these two forms" or something along thos elines
lovetoxi think you misremember, you probably mean IBR
lovetoxwhich has a Dataform, and if you dont support a dataform, here are custom xep defined fileds as fallback
SamCould 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
lovetoxthere is no fallback for "i implemented only half of the dataform xep"
lovetoxbut this would not have anything to do with your lib or?
lovetoxyou just parse a dataform
lovetoxif its 2, then you parse 2
ZashYou don't strictly need FORM_TYPE to render a random form, no?
lovetoxits client business if he displays 2 or 1
lovetoxZash, the problem xmpp should be extensible
lovetoxif the form does not define that its indeed the form from the xep
lovetoxi cannot filter the forms for the correct formtype
lovetoxmeans, if someone attaches a second form, i dont know which one to choose
lovetoxits like if you add a new custom node, without namespace
lovetoxyes its possible , but not really good design
lovetoxto 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
lovetoxi would implement that
lovetoxthats like 5 minutes of work
SamEven 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
lovetoxim didnt read the spec for that, but it seems like a nobrainer
lovetoxlike here have a form, but i dont tell you what it is about
lovetoxdoes not seems like a good solution
lovetoxyou could argue, its probably in the context of how you requested this clear
SamI 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.
lovetoxyes this should be clarified
lovetoxreading the XEP now though nothing idicates that this is not to be expected
lovetoxtitle and instructions are described
lovetoxand later there is one paragraph, about how a table can be displayed in a form
SamRight, but if title and instructions are allowed then why wouldn't fields be?
lovetoxyes, i agree, its not forbidden
SamBut multiple libraries seem to forbid it, so I'm not sure what to do to avoid bad incompatibilities.
lovetoxit would though then really messy in my opinion
lovetoxlike then the order really matters
lovetoxlike what if reported comes in the middle of the fields etc
lovetoxlike its clear that nobody had this use case in mind
lovetoxany sane dev would wrap this in some parent nodes
lovetoxand separate the forms
SamI'm not sure that's true
SamI 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.
lovetoxthere is no way clients support this one way or another
lovetoxits just not a use case until now maybe
lovetoxand now we can decide which way to go
Samyah, 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
lovetoxor do nothing, having one use case in decades of usage
lovetoxits just not supported in xmpp ..
SamMaybe, 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"
lovetoxi doubt this, you have one example where a lib parses both, reported and normal fields into one object?
SamApparently 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.
lovetoxsmacks allows to parse it mixed?
lovetoxor smacks allows to create mixed forms?
SamApparently; that's what someone said earlier
SamBoth, I think? Let me try to figure it out, one moment
lovetoxbecause thats two very different things
Anton L. Šijanechas joined
SamActually, I don't see multi-item forms in Smack at all, so maybe they were wrong
Samoh wait, there it is, looking again
SamYah, 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
lovetoxand then how does it make it accessable by the client?
SamYou can call a method to get fields, you can call another method to get items
SamLooks like it loses ordering info between the two; they're kept ordered, but separate
lovetoxyeah i guess then you have to decide :)
lovetoxof course its not easily doable, you would need to put extra thought into that
lovetoxbut i guess its always, fields first
lovetoxatleast i cant think of a reason why i would display a Table first in GUI, and afterwards some info
lovetoxeither way its probably not critical here
SamIf 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).
SamItems are displayed like columns. If there's a field then more items, then they're just two separate tables with the same header.
lovetoxif i would implement that, i would make something like dataform.add_table()
Samyah, something like that
SamI'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.
lovetoxi 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
SamEmail describing some of this sent to standards@, please mention anything I've left out or if you think I've mischaracterized anything.