[Council] JEP-0020 / JEP-0004 Crossover Issue
mass at akuma.org
Fri Nov 1 14:35:38 CST 2002
So brought up again in the meeting today is the is the functionality of
JEP-0020 can be exposed via x:data - what can be expressed with x:data
is a superset of what is expressed by feature negotiation.
In addition, feature negotiation happens with a multi-user chat room
during the initial configuration and later reconfiguration, but this is
done via the x:data namespace. Would multi-user chat rooms later
support configuration and reconfiguration via feature negotiation, and
how would this differ than x:data based configuration?
It was brought up that x:data is not currently machine-understandable,
that it is human markup for querying the user for data, and a client
couldn't choose options for a client. The one thing needed for this is
an optional registration (with JANA?) of field identifiers along with a
description and valid choices for that field. This is also what would
be required for feature negotiation to work.
Standardization of types of fields may also be a good idea for GUI
display - a client author may want to do layout for something like a
'create room' screen, and only use the generic form renderer if there
are additional fields on the form. They might also want to default
certain options with certain values, or always respond to a certain
form with a specific response. These can all be client-side choices
with field standardization.
So from my point of view, the only difference between the two queries
is that one defaults to having users enter values in response, while
the other defaults to having the application respond. The real question
is whether these need to be separate.
More information about the Council