[standards-jig] disco, x:data, etc...

Thomas Muldowney temas at box5.net
Thu Feb 20 16:12:22 UTC 2003

On Thu, Feb 20, 2003 at 04:58:55PM +0200, Alexey Shchepin wrote:
> Hello, Matthew!
> On 19 Feb 2003 11:53:39 -0800, you said:
>  MAM> First, the admin problems that Alexey is trying to solve are
>  MAM> exactly what x-commands is designed for.  Why not just use
>  MAM> x-commands?
> Because:
> 1) x-commands not indended to include other namespaces than x:data

Have you read the JEP?  Section 3.4 clearly states that pretty much any
extension can be used in a <command/> element.  If the JEPs focus was
limitted to a x:data launcher, I'm pretty sure it would get no where.

> 2) x-commands adds "node" attribute, but also adds useless in this
> case additional element, namespace and more hard processing from both
> client and server side.

I'm confused now, are you against the node attribute in commands?
Personally, I find the commands system simple and clear.  I'm coding it
into JabberStudio's jabber interface to provide interaction with all of
the managers, and so far I have no problems with it.

>  MAM> Second, FORM_TYPE (currently) does not fully address Alexey's
>  MAM> issue,
> IMHO it address jep-0004 issue.  x:data is used both as human-readable
> (i mean human can use it when it showed in client) and as
> machine-readable (e.g. in negotiation protocol).  But:
> 1) From machine side it contain useless elements (like instruction,
> title, and field with type fixed) -- this is not bad, but shows that
> it not only for machine.

x:data was not designed for machine usage, mostly because nothing is
fixed, but JEP-68 is a proposal to make that more clear.

> 2) From client side it looks like a non-extensible and non-flexible
> protocol, because:
>         a) Field types set are fixed.  And fixed with some strange
>         types like "jid-single" and "jid-multi".  Why so many
>         attention to JID?  Of course in some situation we need to
>         enter JID, or list of JIDs, but sometimes we need to enter
>         date, time, etc...  IMHO better replacement for this looks
>         like this: <field type="text-single" subtype="jid" .../> and
>         for date <field type="text-single" subtype="date" .../>.  Or
>         even better to make list of options for each field type.  And
>         IMHO JEP-0068 looks better if it will have no fixed var names
>         for each FORM_TYPE, but will have additional attribute that
>         points to it meaning in given FORM_TYPE.  This helps if this
>         form can have not fixed number of elements (for which we must
>         use different var names).

I personally am not a big fan of having the few fixed types that are
there, but we needed some amount of compromise to get it out the door.
Some people are looking at new JEPs to layer on better type control and

>         b) If we want to display to human list of fields, then we need
>         to know that for human hard to search requred field from list
>         of 30 values, it should contain no more then 10 elements to be
>         easily understandable.  In interfaces this usually solved by
>         grouping of fields.  So if we have <instruction/> and <title/>
>         that intended only for displaying for human, why not to have
>         <section/>, so clients can handle it e.g. by displaying
>         sections in different tabs, by making something like table of
>         contents in beginning of list, or by ignoring it.

I'm missing something, are you wanting to group parts of the form?  Or
section off items in a list?

As a final note, I'm still failing to see how the commands system
doesn't meet your requirements.  Do you have a more clear statement
about where it fails?  I think it's important that any commands issues
are figured out because it can be a very important building block in the


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030220/aac93220/attachment.sig>

More information about the Standards mailing list