- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 9 Jan 2007 18:24:03 -0800
- To: mark.birbeck@x-port.net
- Cc: www-forms@w3.org, www-forms-request@w3.org
- Message-ID: <OFD4737411.A81137D3-ON8825725F.000C568F-8825725F.000D3362@ca.ibm.com>
Hi Mark, Yes, thanks, and ditto :-) I didn't disagree with rich messages. All manner of enriched text could/should be available through host language constructs. For me it breaks when the "rich" in "rich message" becomes so rich that it isn't a message anymore. Because then message isn't a base class for whatever you are ending up with. As you'll see in my response to Leigh, we have to say something about the semantics of message because it has to do something, but I don't think we say more than is necessary. It is a display-only device. This is no different than claiming that the output element is for display only. You say that message is "something that can appear and disappear" whereas I claim it is "a message that can appear and disappear". Moreover, the content model for message was defined to be only chardata and output elements, not repeats. So, at the XForms level, a message is a simple textual string created by concatenating char data with the results of output elements evaluated at the time the message action is invoked. The host language is free to add host language constructs that help beautify that text. But form controls are not text. Finally, note that by erratum, the material relating help to message was removed. 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 "Mark Birbeck" <mark.birbeck@x-port.net> Sent by: www-forms-request@w3.org 01/09/2007 02:57 PM Please respond to mark.birbeck@x-port.net 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/
Received on Wednesday, 10 January 2007 02:24:23 UTC