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

I agree that XForms 1.1 should have a much better thought out dialog
feature; that's one reason I opined against the xforms-close event
without the accompanying xforms-before-close cancellable event.  (Using
explicit dialogs or using event context info to provide a
"don't-close-reason to the user agent are both good ideas to explore.)

But other XForms 1.0 processors do allow the full host content in
message; I believe X-Smiles does this.  So I don't think we should
retroactively go back and say that XForms 1.0 processors can't do it
because the spec merely allows it.  The primary reason we took it out
was to allow mobile phone vendors the option of displaying only text; I
haven't yet located the discussion in the minutes, but we did discusst
that desktop vendors could support html if they supported it.  (A
similar argument was used against output/@mediatype initially, but now
we have it.)  I'm also reminded of Tantek Celik's assertion that HTML
<object type="text/html"> is required for all HTML 4.01 processors,
because they clearly understand HTML.  It doesn't list it in the spec,
but if your read it clearly, you will do it.

Again, to reiterate, I'd be pleased to see dialog in XForms 1.1, but if
we don't get it, I see no problem with message/*/xf:*, as implemented in
XForms 1.0 processors, continuing to work in 1.1 processors.

Leigh.

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Erik Bruchez
Sent: Tuesday, December 05, 2006 2:51 PM
To: www-forms@w3.org
Subject: Re: The message action is for messages, not arbitrary dialogs


All,

John's arguments are quite convincing to me. We have implemented a
dialog extension in Orbeon forms along those lines, and the reasons
for this decision included:

o xforms:message doesn't even hint in XForms 1.0/1.1 that it can be
   used for a dialog. You have to dig deep into the spec and schema to
   infer that, maybe, and with a significant amount of stretching,
   xforms:message can be understood to mean "xforms:dialog".

o I like explicit over implicit. If you say "message", you mean
   message. I don't know of any user interface framework that uses the
   term "message" to also mean "dialog".

o We figured it made more sense to make the dialog container a
   top-level element within the controls, and to use actions
   (show/hide) to show and hide the dialog, very much like what we do
   now with xforms:case and xforms:toggle. This addresses the following
   issues:

   o Event bubbling is problematic and at best confusing if your dialog
     controls are embedded in an action.

   o You may want to open and close a dialog from different event
     handlers without duplicating your dialog or requiring dispatching
     custom events.

-Erik

John Boyer wrote:
 >
 > 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
 >


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

Received on Tuesday, 5 December 2006 23:17:53 UTC