Re: XForms 1.0: My Opinions

Dan Dennedy wrote:

> Thanks for coming through, John. I have noticed some of the things you 
> mentioned while working on my processor. I will make some immediate 
> comments regarding some specifics. (I hate the way Outlook handles 
> reply quotation in HTML--my comments are prefixed by "DRD>.")
>
>     -----Original Message-----
>     From: John Keiser [mailto:jkeiser@netscape.com]
>
>     DRD> Your advice seems very practical. My implementation does not
>     expose so many events esp. the interaction and mutation events
>     partly due to the nature of the processor (server-side using
>     xslt+extension) and the desire to keep it simple and not overload
>     the xhtml with too much javascript. My focus has not been so much
>     on enhancing html forms UI as much as automation and integration
>     into data tier.
>
The interaction events kind of overlap with mutation events, but it 
seems like you need at least one of the two sets for people to be able 
to have a good chance at using JavaScript with their form.  You have to 
be able to catch changes and do things when values change, or the power 
of the scripting model is much diminished.  Of course, I am coming from 
the point of view of a web browser, and enhancing forms UI, so :)

>     - [4.2]: xforms-model-construct and friends: is there a benefit to
>     having these 5 stages of initialization being transparent to the
>     web developer?  Perhaps some of these could go away, such as
>     xforms-model-construct, xforms-model-initialize-done and
>     xforms-ui-initialize?  
>     DRD> I combine stages and only expose notification
>     events initialize-done and model-destruct.
>
Two hooks total seems quite adequate to me :)

>       2. [9.2.1] <switch> is a layout-oriented (it seems to be used to
>     specify a "wizard" interface or split things up for a PDA, or to
>     specify a set of layout stuff that will appear only if a
>     particular expression is true).  It belongs in a layout-oriented
>     spec such as SVG or XHTML.  
>     DRD> Well, as you pointed out elsewhere there are things that are
>     layout-oriented in XForms. There are a few containers for
>     controls, and switch basically is like a mutually exclusive set of
>     <group>. Perhaps it could be removed, and one could change some
>     instance data that a relevant expression refers to followed by a
>     recalc/refresh.
>
Actually, as far as I can tell, <group> exists solely to set a context 
node for controls underneath it.  I don't begrudge that; it's more a 
control structure than anything.  <switch> actually says that controls 
will be shown / not shown / etc. depending on certain values.

>     DRD> On a related note, label is layout-oriented too. Obviously,
>     XForms supports CSS absolute positioning, but many (most?) prefer
>     a flowed or managed layout. In that case, should labels always go
>     on the left? Many form authors prefer top or bottom. Some authors
>     prefer right-aligned over left-aligned esp. if one or more labels
>     are rather long. Can all of this be specified in CSS using
>     "caption-style" and "text-align"? Not only is the label aligned
>     relative to its control but most forms require alignment between
>     controls for nice, orderly layout. So, an XForms client could
>     define a vertical box model to support this, but then there will
>     be the need to layout more than one field per line. Therefore, my
>     processor supports an attribute on <group> to specify a
>     horizontal, vertical, or freestyle arrangement. Freestyle
>     arrangement basically allows the author to use any xhtml, but the
>     author still loses control due to the nature of the label being a
>     child (or potentially attribute) of the control. This is a very
>     important issue with respect to web forms because XForms will be
>     very quickly dismissed by web authors if this is not expressive,
>     flexible, and simple. Despite the fact that we need to push them
>     towards more separation and abstraction, etc. if they can't get it
>     to "look right" for the majority of their audience, they will give
>     up!
>
It seems to me that label is semantic data ("this text or HTML 
identifies the control in question visually"), and the presentation of a 
label is up to CSS.  Perhaps CSS is not up to handling it; I haven't 
even investigated that yet.

>     3. The syntax is generally too element-oriented and does not allow
>     attributes in enough places; [8.1.10] <select*> is particularly
>     bad about that.  This makes it hard to write.  [8.3.3] "label" in
>     particular needs to be specifiable as an attribute (like <trigger
>     label="Click here">).  It's too commonly used to require the bulky
>     element syntax.  This will make things more readable and easier to
>     write.  
>     DRD>   I have to concede that it is quite verbose compared to what
>     html authors are used to, but it is something I have personally
>     learned to live with. Even though the inspiration is to allow for
>     links to external resources and internationalization, I like the
>     idea of the option of an abbreviated syntax because our clientele
>     rarely needs that. For example, RDF/XML specifies both elements
>     and an attribute-based abbreviated syntax.
>
Yes, I understand the need for an element--but I also believe that most 
of the time it will not be needed, so allowing the option of an 
attribute would be best.

>     4. [10] actions look like an attempt to define yet another (very)
>     basic scripting language in XML.  Why, when other scripting
>     languages already exist?  I can see the need for the most common
>     of these actions, but I think only the most common ones that would
>     be done in a <trigger>--send, reset, and some sort of script
>     (unless there is an easy way to specify event handlers in XForms /
>     XML without resorting to a JavaScript onLoad handler?).  Let
>     uncommon actions be done in script--we don't need two versions of
>     every function, and all functionality needs to be in a DOM, so
>     <action> is the one where we should be parsimonious.  I hear the
>     rule of thumb in the WG is 80%/20% ... that's an admirable goal,
>     but I doubt 80% of it can be dealt with, period.  Many buttons are
>     just too custom.  A more reasonable goal is "the most common
>     functions people will expect to have in the browser."  This
>     includes reset and submit by default (to migrate from HTML), and
>     probably includes insert and delete.  script can handle the rest.  
>     DRD> This is going to be a tough issue.   There is no current work
>     on a DOM--not even planning AFAIK. Most of the actions simply
>     dispatch their corresponding event, and can be expressed using the
>     longer form <dispatch> action. Not sure what else to say here. As
>     far as simplicity goes, either the author would need to know the
>     name of the event to handle and script, or the author needs to
>     know the name of an action that triggers a corresponding event's
>     default behavior. Since we have no DOM and scripting interface
>     right now, does it make sense just to keep the actions?
>
I prefer if we simply work on a scripting interface instead of building 
a separate one in XML :)  I'll try and work one out.

>     5. [8.1.4] textarea doesn't seem to have attributes for
>     columns/rows (perhaps this is a CSS thing) ... a   
>      
>     DRD> This is a good point. My processor supports cols and rows
>     attributes. Basically, it generates xhtml and passes through all
>     foreign (non-XForms) attributes.
>
The main difficulty with cols/rows is with variable-width fonts.  The 
more I think, the more I suspect CSS is more in charge of this than 
xhtml, though.

--John