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

Hi Leigh and Mark,

Well, my main intent in the first email was just to separate chameleon 
namespacing from whether or not message can contain particular things.

But the spec actually does contain lots of language that prevents adding 
interactive content to a message.  It defines a message action as that 
which displays a message.  It is display only.  The content model is then 
defined as a mix of char data and xforms output only.  No other XForms 
elements are allowed in message, neither atomic form controls nor groups, 
switches and repeats.

Then, someplace else in the spec it says that you can add host language 
content to UIInline.  Well, great, but XForms controls are not part of the 
host language, they are part of XForms.

So there is nothing in the spec that says you can add any XForms element 
other than output into the content of message.

This is the point where Ulrich indicated that it would be a little less 
clear once 1.1 allows chameleon namespaces because the XForms elements 
will be in the same namespace as the host language.  My reply was just 
that the definition of message as a display-only construct is strong 
enough that it should survive this.

Mark's response then indicated that I had somehow excluded enriching the 
text.  I don't think I did because the spec does say you can add strongs 
and ems and what have you from the host language.

As for issuing an erratum, or making a change to 1.1, I think we can leave 
it be for now.  I just wanted to raise awareness of the fact that there 
are several implementers who don't have this feature, and so it's not 
interoperable right now.  Moreover, turning it into a feature has problems 
because of event bubbling and because message can appear in the model and 
be invoked before the UI is created.

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/09/2007 04:31 PM

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







I agree with Mark; I think nothing in the spec prevents it, but I also
agree with John and Erik that having xf:dialog with additional semantics
(possibly transactional, possibly recursively componentized) is
valuable. 

I raised this issue initially because I want to make sure that we don't
issue an erratum slapping the wrists of 1.0 processors that do it, and
because I want the 1.0 processors still in development to consider it if
they can implement it. 

I am saddened that 1.1 WD doesn't contain xf:dialog, but that's water
under the bridge.  As of right now, there's always the possibility of
contributing ideas on xf:dialog to exforms.org and I would encourage
Erik and anyone who is interested in recursive component construction to
contribute ideas as well.

Leigh. 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Tuesday, January 09, 2007 2:58 PM
To: www-forms@w3.org
Cc: www-forms-request@w3.org
Subject: Re: The message action is for messages, not arbitrary dialogs


Hi John,

First, I hope you had a good break, and all the best for 2007.

> And, in any case, the whole issue remains orthogonal to the issue of
what markup
> is expected to function interoperably within an xforms message.  The
XForms
> schema does *not* include *any* host language markup in a message.
Host
> language authors are encouraged to add host language  constructs, but
this does
> not in my view mean that they are allowed to add *all* host language
constructs
> everywhere since doing so violates the definition of the construct
(message).

I can see what you're trying to do, but I worry about being so
prescriptive, and I disagree that allowing rich messages goes against
the 'definition' of 'message'.

In my view, a message should be seen as more akin to a 'base class'
that has fairly clearly defined behaviour, but no claim can be made
about the semantics. It is something that 'appears' at some point, and
then depending on the value of @level, it will either disappear
automatically, or it requires the user to make it disappear. Beyond
that there is little more you can say about 'message', and in this it
is not unlike switch/case.

One reason I make the point about it being a base class that defines
*behaviour*, is that in XForms, 'help' is defined in terms of
'message'. In many help systems the help page you look at can do all
sorts of things, like have a tree view of contents, allow you to
search for help topics, and so on. If you start saying that the
semantics of 'message' are that it does not contain form controls then
that would preclude making 'help' behave in any other way than the
limited way that you are suggesting 'message' does.

But if you say that a message is simply something that appears and
disappears--i.e., it is defined by its behaviour, rather than its
purpose--then 'help' can nicely layer semantics onto 'message', but
retain the functionality.


> It is pretty clear that the host language constructs to be added are
those that assist
> in diplaying a better message to the user (like bold, font changes,
etc).  Other uses
> of UIInline might allow more constructs as appropriate to the
situation.

I'd also worry about defining 'message' as something that can't take
form controls. For example, surely repeat, group and switch/case are
useful inside a 'message'? And once they are accepted as useful
(indeed, necessary) ways of creating rich responses for users, then
it's difficult to see what is gained by preventing other controls from
appearing in a message.

You could insist that they don't appear, but then you're left with
very basic messages, and you would also need to come up with a
*semantic* definition of 'message' that justifies this limitation.
Saying that messages are only 'one way' obviously does not rule out
using repeat, etc.. so that would not be good enough. And as it
happens, since in the approach I am advocating the action of the
'message' in and of itself does not return any data, then even
including a handful of input controls does not prevent the message
from being regarded as 'one way'.

(I should clarify that in formsPlayer you could have XForms, SVG and
MathML inside a 'message', and I see nothing in the spec that prevents
this.)

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/