[standards-jig] disco, x:data, etc...
alexey at sevcom.net
Thu Feb 20 14:58:55 UTC 2003
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
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
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
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