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

Hi John,

> Well, we're kind of going around in circles here.  Prior emails have already indicate that
> you cannot add *anything you like* to UI.Inline.  That's not what it says.

I know that this has been asserted, but I haven't seen a good
explanation for why. (If I missed it, I apologise.) My point is how do
you stop it? What can you put into the XForms language that prevents
the host language from adding 'antything it likes'? Your argument is
that you don't need to add anything, because that's the 'spirit' of
UI.Inline, i.e., it was never intended to be extended. My argument is
that unfortunately that isn't strong enough; if we wanted to prevent
this, we should have defined the (normative) schema differently. We
didn't, and so extension is perfectly legitimate.


> Adding *anything we like* to message means we can add *anything we like* to label
> as well.  So, you can put a whole subform in a label?!?

Why not? I can only say what I said in my previous email, that I think
we should avoid having too fixed an idea of what a form is.


>  As with message, that is not the intent of label at all.  I don't think it is the intent
> of help, hint and alert either, but bending label to be a whole subform seems to
> illustrate the point particularly well due to the breakdown of accessibility that ensues.

My point before was that when dealing with an abstract language, it is
difficult to pin down what exactly any control 'is'. Even more
difficult is establish 'intent'. :)

I remember the group arguing over whether to retain xf:output within
xf:label, when @value was added. That seems a long time ago, and I'm
sure no-one today would disagree that it is needed, and to me this is
much the same. Why shouldn't label contain a xf:repeat, for example?
That doesn't seem like "bending" label to be a sub-form, but an
important feature.

And there is no reason that accessibility should break down; if all
controls are accessible, then combining them together should also be
accessible.


> From that vantage point, it should be clear that the purpose in allowing elements of
> the host language in message, label, help, hint and alert is to make their "messages"
> display in a more friendly manner.

As in my previous email...I can only say that this is not something I
get from the spec, and is more a question of interpretation.


> This is not to say that the mandate of some of these elements should not be expanded
> to the use cases that folks would like to solve.  But the push back here is that
> implementations which don't already use message as a dialog are not broken.

That's ok--I don't have a problem with that. But surely the behaviour
is determined by the *combination* of XForms and the host language,
and not XForms on its own. So if some implementation does not support
the use of XForms within xf:message, that is not a failure at the
XForms level, and is simply an implementation choice at the host
application level.


>  More careful examination would be needed to turn message into a dialog, including
> doing so in a way that does not also turn label into a group.

See above. ;) (I.e., I don't agree, and that is up to the host language.)


>  Moreover, the push back
> is that it might make more sense to leave message as a message and make a
> dialog construct to solve the dialog problem.

I'm having trouble seeing what it is that we're trying to achieve
though. It seems to me that the argument is for one particular style
of implementation of xf:message, and a restriction on XForms that
conforms to that. But that is the cart driving the horse. If a
language that contains XForms is able to implement a xf:switch/xf:case
then it can easily implement a xf:message in the same way formsPlayer
does. If the host language/implementation combination chooses not to
do so that's fine, but it shouldn't be said that this is because
implementing 'rich messages' is difficult.

The only way I can see that you could do exactly what you want is to
define a profile that combines a host language (say XHTML) with
XForms, and restricts xf:message, xf:hint, xf:help, xf:label, etc., in
the way that you want. That way, XForms itself remains flexible, but
there is a language that can be used that people will know will always
work across the board.


> This also doesn't mean that those whose messages already behave like dialogs
> should just drop what they're doing.  People have to innovate and find out what works,
> and they want to keep those things working until a migration path can be defined,
> which necessitates having the language feature show up to migrate to.  Maybe the
> migration path is null, but maybe it isn't.

I don't disagree with this, but this view is based on the idea that
the host language is not free to 'host' XForms in whatever way it sees
fit. Although we often say what a host language should do, we don't
say what it shouldn't, so in my view our (formsPlayer's) approach to
xf:message is not about innovation or experimentation, but a
straightforward reading of the specification.

To be clear on why I am pushing these points, the important issue here
is not xf:message, but the broader principle of whether a host
langauge is prevented from using XForms in a way that it sees as
appropriate. I feel it is a big leap to assert this, particularly when
the argument to support this view relies--with all respect--not on the
letter of the specificaion, but on notions such as the 'intent'.

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, 17 January 2007 10:26:50 UTC