RE: XForms 1.0: My Opinions

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] 
	

	1. There is a huge number of events in the system that adds more
confusion than it helps.  Some of these events, such as xforms-activate
and even to an extent value-changed (mutation events), duplicate
functionality in the DOM3 Events module.  Others seem unnecessary or
redundant.  Events do not exist to expose every single step of an
implementor's algorithm.  Events are meant to be useful hooks for
scripts.  This seems like a good rule: "don't add an event unless
somebody can think of a good conceivable use for it."  Please also
remember that mutation events targeted at the instance data should take
care of even more things than this spec takes care of. 
	 
	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.
	
	- [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.
	 
	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.
	 
	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!
	
	SUGGESTED CHANGES:
	- Remove <switch> / <case>
	
	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.
	  
	
	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?
	
	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.