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