Re: On running a pre-processor [RE: XForms timer]

Mark Birbeck wrote:

 > Leigh didn't actually mention submission in his example, but I think we
 > agree that when people talk about 'Google suggest' they usually mean 
that a
 > list is obtained from a server or something.

Agreed.

 > But my point is that we are asking the author to 'wire' these
 > components together; they have to create the submissions, the
 > itemset, and so on. And if you have four or five of these suggestion
 > lists on a form, that's a lot of 'wiring' you are asking an author
 > to do.

Let's say "a little bit" of wiring:

o selection="open"
o xforms:itemset
o xforms:send and xforms:submission

These are already familiar to XForms users, and they are used here in
a way 100% compatible with the way XForms intends them to be used.

To clarify my point: I am not saying the current "wired" approach is
the ideal one, or that there is an ideally small amount of wiring,
just making the point that it's maybe not as difficult as you made it
sound. In other words, as a stopgap measure until XForms ideally
addresses the situation of autocompletion, it's pretty good.

 > In other words, once we have recognised the *pattern*, we should
 > wrap it in some convenient mark-up. (There is nothing in the notion
 > of 'suggestions' that implies a select1. And there is also nothing
 > to say that your list of 'country suggestions' should be the same as
 > my list. Your list might contain previously entered values, plus
 > some that come from your company intranet...my list might contain
 > entries that I've put into del.icio.us, etc.)

Agreed.

 > The second way of proceeding is to simply add the attribute to
 > formsPlayer, document clearly how the attribute indicates which set
 > of submissions and instances to use, and then leave it to authors to
 > decide whether they use the feature or not.
 >
 > I don't like that approach, because I'd like people to be able to
 > follow our tutorials and not have to keep looking over their
 > shoulder as to whether they are straying from the XForms
 > specification or not.

Another way is just to say that doing the wiring by hand is good
enough, and just add a custom appearance (XForms implementors could
even agree on it, or even use appearance="minimal" as Leigh suggested,
although I am not necessarily convinced by that approach), which is
allowed by the spec.

If your XForms implementation does not support the autocompletion
appearance, then the application will still work, but you will have to
pick the completion by hand in a list - a sort of "graceful
degradation".

 > So I'm suggesting a third way, which is to use a pre-processing step
 > which will allow us to play with new features and learn a lot about
 > how they work, before finally deciding which ones really are useful
 > and which are not.  Provided that the output from the pre-processor
 > is still XForms, everything will still work in any of the current
 > processors, and therefore anyone can make use of the pre-processor.

You know that in principle I agree with this suggestion.

But I have some questions on the specifics. For example, a particular
implementation my have, today, a built-in suggestion widget, like
OPS. Another one may prefer to implement that widget using XForms
itself, like FormsPlayer. I believe both approaches are valid. So the
question is:

1. Whether we just agree to agree on the format of the *input* of that
    transformation layer, or

2. Whether we also aim at having a common XSLT stylesheet which, in
    the situation I mention above, is not optimal.

-Erik

-- 
Orbeon - XForms Everywhere:
http://www.orbeon.com/blog/

Received on Saturday, 20 May 2006 14:51:28 UTC