[jdev] Reproducability of XEP-0115: Entity Capabilities - 5.3 Complex Generation Example

[Ralph Meijer]

On Tue, 2008-05-06 at 09:43 +0200, Yann Leboulanger wrote:
> Ralph Meijer wrote:
> > On Tue, 2008-05-06 at 00:35 +0200, Yann Leboulanger wrote:
> >> Peter Saint-Andre wrote:
> >>> We assume that the client received a dataform of type "form" and then
> >>> submitted it (no need to include the types there because the entity
> >>> you're submitting to sent you the form in the first place), and yes I
> >>> think the client would need to remember the types it received in the
> >>> dataform of type "form" in order to properly parse the result. But we
> >>> could tighten up the spec on this score if that is desirable.
> >> That's not always True. For example in XEP-0128, we get a result form 
> >> without having previously requested anything, so we have no way to know 
> >> which type of field it is.
> >>
> >> This is a problem currently in Gajim as our DataForm parser accept 
> >> several values element only in list-multi. So it doesn't parse correclty 
> >> dataforms from XEP-0128. So we can't compute correclty caps hash (it 
> >> contains those values)
> >>
> >> But I'm not sure it's a good thing to guess field type from the number 
> >> of values elements in it ...
> > 
> > You can know the types of the fields because of the scoping by the
> > FORM_TYPE field. Yes, this would require you knowing about the fields
> > you can expect, but you need that for further processing anyway.
> 
> ok so you mean that clients are supposed to hard code registrar from
> http://www.xmpp.org/registrar/formtypes.html ?

I assume that you want to be able to process certain forms in their
context. The context here is the form type, and so yes, if you want to
be able to machine-process forms, you need to consume the form fields in
the namespace (= form type) they occur in. I suppose that you could
refer to that as 'hard-coding', I would just call it 'proper coding'.

> > You don't need to know about the types for hash calculations, since this
> > is not the place to actually validate the form. It only needs to be
> > well-formed and adhere to the Data Forms schema.
> 
> Right, but it's sad that we have to write another parser to compute caps
> and not use our standard data forms parser.

The 'scanning' of forms, as opposed to parsing, can be done generically.
On top of that you can build a function to compute the part of 'S' that
is hashed to calculate the verification string for Entity Capabilities,
as well as parsing the scanned tokens for further form processing. You
don't need to put the validation of types and values in the scanner.
That is an implementation design decision.

-- 
Groetjes,

ralphm