W3C home > Mailing lists > Public > www-forms@w3.org > December 2006

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

From: John Boyer <boyerj@ca.ibm.com>
Date: Mon, 11 Dec 2006 11:03:18 -0800
To: "Ulrich Nicolas Lissť" <unlisse@googlemail.com>
Cc: ebruchez@orbeon.com, "Elliotte Harold" <elharo@metalab.unc.edu>, www-forms@w3.org, www-forms-request@w3.org
Message-ID: <OFAF9687C9.114DD0F5-ON85257241.0067E9C3-88257241.0068AC20@ca.ibm.com>
Hi Ulrich,

Even as I wrote, I knew someone would raise the chameleon namespace issue, 
but I didn't address it in my message because I would have then been using 
my message as a dialog!

Anyway, the chameleon madness is being done to appease the concerns of 
those who complain that form authoring becomes too complicated once 
namespaces are involved.

But, for starters, the XForms design still recognizes its own vocabulary 
distinctly from the "host language" even when they are in the same 
namespace.  In other words, the advocates of simplified authoring are 
saying that they don't want namespacing to be the mechanism by which 
responsibilities are divided, but that does not mean the responsibilities 
are not still divided between the XForms processor (for the XForms 
vocabulary imported) and the host language processor (for markup not 
imported from XForms).

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).

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.

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





"Ulrich Nicolas Lissť" <unlisse@googlemail.com> 
12/11/2006 05:31 AM

To
John Boyer/CanWest/IBM@IBMCA
cc
"Elliotte Harold" <elharo@metalab.unc.edu>, ebruchez@orbeon.com, 
www-forms@w3.org, www-forms-request@w3.org
Subject
Re: The message action is for messages, not arbitrary dialogs






John,

I agree completely. A message is a message is a message. However, when
the XForms 1.0 xf:message content model will be included in XForms 1.1
unchanged, things are getting ugly: You can then have XForms markup
within xf:message piggy-backed via the host language because of
XForms' 1.1 chameleon schema feature. One compelling reason more for
me to opt against chameleon madness.

Regards,
Uli.

On 12/8/06, John Boyer <boyerj@ca.ibm.com> wrote:
>
> Hi Elliotte,
>
> I should start by saying that, having heard you speak at the XML 
conference, this response is not entirely directed to you.
>
> Still, it is quite difficult to imagine a scenario in which 'message' 
might legitimately be used in place of 'dialog' and the many examples you 
cited are witnesses to that assertion.
>
> This keeps happening because of the definition of the word message.  A 
message is one-sided.  A dialog would be composed of two or more messages. 
 Like, you sent a message, and now I'm sending a message.  The two 
together are a dialog.
>
> But the most telling is the definition of message that actually appears 
in XForms recommendation.  It is defined to *display* a message *to* a 
user.  There is nothing *from* the user that comes back to XForms.
>
> The content model is defined to be char data and XForms *output*.  The 
spec then allows host language content to be added to message, which is 
*not* the same as saying more *XForms* controls can be added to the 
message content model.  The host language additions are not intended to 
violate the given definition but rather in support of it to allow 
decoration of the message.
>
> Should some example happen to arise where message is (mis)used to mean 
dialog, that doesn't mean we should accept that as proper usage in XForms.
>
> 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
>
>
>
>
>
> Elliotte Harold <elharo@metalab.unc.edu>
> Sent by: www-forms-request@w3.org
>
> 12/07/2006 07:46 AM
>
> Toebruchez@orbeon.com
>
> ccwww-forms@w3.org
>
> SubjectRe: The message action is for messages, not arbitrary dialogs
>
>
>
>
>
>
>
>
>
> Erik Bruchez wrote:
>
> > 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".
> >
>
> Google MessageBox. .NET, SWT, and ASP.NET all use this term instead of
> DialogBox. Possibly they think of MessageBox as a restricted form of
> DialogBox just for messages; i.e. an alert. I'm not sure, but certainly
> the word message is sometimes used in place of the word dialog.
>
> --
> Elliotte Rusty Harold  elharo@metalab.unc.edu
> Java I/O 2nd Edition Just Published!
> http://www.cafeaulait.org/books/javaio2/
> http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
>
>
>
Received on Monday, 11 December 2006 19:03:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:08 GMT