- 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 UTC