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

Alexey Shchepin alexey at sevcom.net
Thu Feb 20 14:58:55 UTC 2003

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?


1) x-commands not indended to include other namespaces than x:data

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.

 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.

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

        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.

More information about the Standards mailing list