The message action is for messages, not arbitrary dialogs

Well, team, based on being the most hotly contested issue at the working 
group face to face meeting, we do need to spend some time discussing the 
meaning of the message action.

The following is my opinion offered to initiate discussion by the working 
group and the XForms community.

At the working group face to face it was suggested that we should not 
disallow message from acting as a general dialog just because it is 
spelled m-e-s-s-a-g-e.

Yes, we should.  For starters, the name of the thing should reflect what 
it does.  Otherwise, why not name all of our vocabulary foo1, foo2, ..., 
fooN instead of insert, delete, input, ..., repeat.  If you want a dialog, 
use d-i-a-l-o-g.  Moreover, if the lessons learned about the new prompt 
action in 1.1 are any indication, a dialog *action* should almost 
certainly not directly contain the UI content for the dialog.  The dialog 
UI content should be indicated by reference so that the capture and bubble 
phases of events for controls within the dialog do not trigger behaviors 
from the containing UI control(s) that activated the dialog.

At the face to face, it was shown that the content model for message 
includes UIInline, which the spec says that a host language *should* add 
inline host language markup.  As a minor technicality, we can't really say 
*should* about the host language.  We can only say *may*.  But regardless 
of the categorization, the claim is that this sentence means that host 
languages can put any host language constructs into message.

First of all, xforms:input is from XForms not the host language, so 
changes of UIInline should not include any input controls from XForms. 
Moreover, observe that the spec is clear on what elements from XForms can 
appear in message: output.  Finally, just because a host language *may* 
add host language markup to the message element does not mean that the 
host language is allowed all of itself to the extent of violating the very 
definition of the message action.  Designers of host languages 
integrations with XForms are expected to be discerning about what gets 
added and what is allowed to work.  Perhaps XForms could be a little 
better defined by separating this use of UIInline from others, but the 
definition of message is as follows:

"This action encapsulates a message to be displayed to the user."

The above definition for message categorically does not admit a two-way 
dialog with the user.  The intent of the action is to provide a simple, 
lightweight ability to provide information *out* to the user.  The ability 
to make host language additions is intended to support that definition by 
providing a means to enrich the presentation of the message, not to allow 
an end-run around the definition of 'message'.

We have a future requirement to create a dialog construct.  Let's do that 
so that we can curb the tendency to misuse message as the feature we need 
but don't have.

Thanks,
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer