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

Hi John,

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

I think to be worthy of inclusion in XForms, 'message' needs to be a
bit 'richer' than just supporting bold text. I specifically chose
repeat and group in my comments because they are constructs that
'enrich' the message, whilst still leaving the message in a form that
fits your definition of a message (i.e., purely 'output'). For
example:

  Orders #344, #345 and #346 will be sent in one shipment. Please note that
  the iPod, garden shears and spaghetti drainer are out of stock.

Two repeats are needed there.


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

My point was that because all you can really say about message is what
it does, then we only need to say something about its behaviour in a
general, device-independent, sense. You are trying to retrofit
semantics onto something which never had any, which is always going to
cause problems.


>  It is a display-only device.  This is no different than claiming that the output
> element is for display only.

We're dealing with abstract controls, so never say 'never'. :) For
example, it is trivial to create an output control that renders a
Google Map centred on the long/lat value that is contained in the
instance node bound to the control. Should the user be prevented from
navigating around that map, zooming in and zooming out, adding
pushpins, and planning routes? Of course not. So given that an output
control can have user interaction, just about all you can say about
'output' is that it should be used in situations where the user should
not modify the underlying instance data. The alternative
definition--that output "is for display only"--is extremely difficult
to pin down when dealing with abstract, device-independent controls.


> You say that message is "something that can appear and disappear" whereas
> I claim it is "a message that can appear and disappear".

If you had defined "message" in the glossary section of XForms 1.0
that would be fine. But to now restrospectively try to impose
semantics onto something that has never had any is only going to cause
problems.


>  Moreover, the content
> model for message was defined to be only chardata and output elements, not repeats.

We've discussed many times that the host language can include its own
elements which in turn can include XForms. To see why that is the only
way you can really approach this just try the opposite approach: In
the XML Schemas we have for compound documents, which support XForms
and SVG within XHTML, we allow svg:svg and the XForms model and UI
elements inside xh:div and xh:span. We then further allow xh:div
inside of xf:message; how do we now *stop* the use of these XForms
elements, only when the div and span are inside message? And that is
not just a technical question relating to XML Schemas--what is the
basis on which we disallow it? How do we define something in XForms
that places a limitation on the host language?

(I'd have no problems with defining XForms Basic in such a way that
you limit what the host language can do.)

But I don't even accept that a 'message' is simply 'some output'. The
following simple mark-up shows a message--in the sense of 'some
output'--but it also collects some information from the user in the
process. The 'message' does not 'return' this data; as I've said
before, all a message does is render itself, and then wait for the
user to dismiss it:

  <xf:bind nodeset="dontshowagain" type="xsd:boolean" />

  <xf:message if="not(dontshowagain)" ev:event="...">
    You've done something dumb.
    <xf:input ref="dontshowagain">
      <xf:label>Don't show me this message again</xf:label>
    </xf:input>
  </xf:message>

We've allowed this kind of functionality in formsPlayer for years, and
I'd argue that far from going *against* the spirit of the spec, it is
*exactly* the kind of thing that you want from a flexible,
declarative, forms language.


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

That is your view, and not one supported by the XForms specification.
With respect John, I think you're going to find it very difficult to
define such a prescriptive behaviour. Should 'message' also prevent
SVG content? If it allows it, should it prevent script handlers from
running so that clicking on a red rectangle does not cause a script to
execute that updates the instance data?


> Finally, note that by erratum, the material relating help to message was removed.

Indeed. My point though is that we have a 'container' that has
behaviour, and we can build on that conceptually. It's all very well
constantly redefining things to be understandable only in their own
terms, rather than in relation to other things, but that makes it much
more difficult to learn the language.

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 12:14:13 UTC