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

I agree that implementations that don't allow xf:* in xf:message are not
broken.
If you agree that implementations that do allow xf:* inx f:message are
not broken then we are done.
 
I really want to get the xf:dialog work done, and I think the XAC work
from Rafah Hosn and Charlie Wiecha is quite exciting, and want to hear
more about it.
I'm also just beginning to learn about the xxf:dialog done by Erik
Bruchez at Orbeon.
I'm sad it's not going to be in XForms 1.1, but that's how it goes.
 
Leigh.

________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Tuesday, January 16, 2007 4:35 PM
To: Klotz, Leigh
Cc: mark.birbeck@x-port.net; www-forms@w3.org; www-forms-request@w3.org
Subject: RE: The message action is for messages, not arbitrary dialogs



Well, we're kind of going around in circles here.  Prior emails have
already indicate that you cannot add *anything you like* to UI.Inline.
That's not what it says. 

Adding *anything we like* to message means we can add *anything we like*
to label as well.  So, you can put a whole subform in a label?!?  As
with message, that is not the intent of label at all.  I don't think it
is the intent of help, hint and alert either, but bending label to be a
whole subform seems to illustrate the point particularly well due to the
breakdown of accessibility that ensues. 

>From that vantage point, it should be clear that the purpose in allowing
elements of the host language in message, label, help, hint and alert is
to make their "messages" display in a more friendly manner. 

This is not to say that the mandate of some of these elements should not
be expanded to the use cases that folks would like to solve.  But the
push back here is that implementations which don't already use message
as a dialog are not broken.  More careful examination would be needed to
turn message into a dialog, including doing so in a way that does not
also turn label into a group.  Moreover, the push back is that it might
make more sense to leave message as a message and make a dialog
construct to solve the dialog problem. 

This also doesn't mean that those whose messages already behave like
dialogs should just drop what they're doing.  People have to innovate
and find out what works, and they want to keep those things working
until a migration path can be defined, which necessitates having the
language feature show up to migrate to.  Maybe the migration path is
null, but maybe it isn't. 

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 

01/10/2007 02:40 PM 

To
<mark.birbeck@x-port.net>, John Boyer/CanWest/IBM@IBMCA 
cc
<www-forms@w3.org>, <www-forms-request@w3.org> 
Subject
RE: The message action is for messages, not arbitrary dialogs

	





On this topic, I recall that this was an explicit compromise decision
between the 2-line LCD phone and the desktop HTML browser.

> So there is nothing in the spec that says you can add any XForms
element other than
> output into the content of message.
Yes there is...I can add anything I like to UI.Inline. (See above.)