RE: The message action is for messages, not arbitrary dialogs

Hi Leigh,

Thanks for digging up the early minutes on this issue.  The struggle 
between allowing the (error) message to be only plain text versus allowing 
host language markup to dress up the message can be seen. 
It seems pretty clear that not a lot of consideration is given to bending 
message into something that can do full dialogs.  Otherwise, the content 
model just within XForms would not be just a mix of characters and output 
elements only.

Cheers,
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





"Klotz, Leigh" <Leigh.Klotz@xerox.com> 
Sent by: www-forms-request@w3.org
12/04/2006 05:28 PM

To
John Boyer/CanWest/IBM@IBMCA, <www-forms@w3.org>
cc

Subject
RE: The message action is for messages, not arbitrary dialogs






 
Date: June 19, 2001 
- error
Sebastian: "error"?
Micah: What about just "message"?
Roland: We haven't talked about the processing model for "error message".
We have talked about caption, hint, and help. 
Micah: We could merge them because they have the same content model.
Roland: They do different things.  The issue is the processing model.
Sebastian: How about "alert"?
Leigh: Then it will have a JavaScript alert box.
Sebastian: Not on cell phones.
Doug: So is it for failed validation?
Sebastian: No.
TV: The help is shown when the user asks for help; the hint when the user 
hovers; the caption next to the item.  We need to decide when the alert is 
shown.
Sebastian: So we could have an action that triggers it.
TV: So we have two proposals: add an alert element as a peer to
hint/caption/help, and the processing model says to show it when there
is an alert inside a widget and will be shown when validation fails.
Also add an alert action handler.  You can use this for rollovers.
Micah: And add action for hint and help.
Sebastian: For example you can define an alert in a button element (which 
has no validation) and trigger that.
Josef: What is the content model?
Sebastian: Plain text.
Josef: That's different from help and hint.
TV: If XHTML is the host language, then the content model for help and 
hint is XHTML; it's wrong for us to over-specify it. 
Micah: The content model for help, hint, and alert is #ALL.

From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf 
Of John Boyer
Sent: Saturday, December 02, 2006 10:06 AM
To: www-forms@w3.org
Subject: 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