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

Hi John,

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

I agree. They are two different issues.


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

There is not only no definition of message in the glossary (see my
other mail) but there is also no definition of 'display'. We're
dealing with device-independent, abstract controls, and the spec is
actually quite weak on this kind of thing. But certainly there is
nothing in what people would generally accept as a message that
prevents some kind of user interaction taking place. ("Don't show me
this again", "Did you find this message useful?", "You have not
entered a valid ID number. Please enter it here:..." and so on. These
are all commonly used techniques.)


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

We've discussed this many times; XForms is designed to be *hosted*. It
is up to the host language what can be included in what.


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

We've discussed this before, too. If I say in my host language that
xh:div and xh:span can contain xf:repeat, and then add xh:div and
xh:span to UI.Inline, what is wrong with that? If I'm not allowed to
do that, what meaningful definition of 'message' (or UI.Inline) would
you create that prevented this? And would you also prevent the
inclusion of MathML and SVG? Script handlers?


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

Yes there is...I can add anything I like to UI.Inline. (See above.)


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

You're talking here about some definition that you are proposing to
add, because the spec itself is very vague.


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

I was talking about something different; using repeats to show a list
of items in a message is not 'enriching the text', it's the only way
to actually get the information that is needed out of the instance so
that it can be presented to the user. Of course, for some things you
can use concat(), but that only works for simple lists; we have
xf:repeat, why not use it?

(Enriching the text with bold and italics should be taken as a given,
but XForms should be much more powerful than that.)


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

I don't disagree that an interoperable way of doing things would be
useful, but the problem is not solved by restricting message; far
better to *add* a new kind of message that doesn't have the same
problems of interoperability, rather than trying to redefine 'message'
and so limit functionality.

As it happens, we this is part of a general problem, caused by the
fact that XForms sits inside host langauges. So whilst different
*processors* will all support XForms, the host application may support
different features. But I think one part of tackling this is to make
it clear how to create interoperable forms, via community sites,
samples and tutorials. (I.e., show examples that don't use any
advanced features.)

Also--and this is longer term--we need some way of detecting what a
host application is capable of, so that at run-time a form can make
use of richer features, should they be available, but fall back if
they not.

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 11:07:05 UTC