W3C home > Mailing lists > Public > www-forms@w3.org > September 2002

XForms 1.0: My Opinions

From: T. V. Raman <tvraman@us.ibm.com>
Date: Thu, 5 Sep 2002 16:41:33 -0700
Message-ID: <15735.60333.303701.436809@bubbles.almaden.ibm.com>
To: jkeiser@netscape.com (John Keiser)
Cc: www-forms@w3.org, Beth Epperson <beppe@netscape.com>, Daniel Glazman <glazman@netscape.com>


John --

When we specified the XForms processing model as we did in the
specification we had two goals:

0) Not to specify it  in terms  of a given algorithm or implementation

and 
1) at the same to ensure that the same form gave the same answer
irrespective of how you implemented the processor.

We achieved this by specifying the processing model declaratively i.e.
in terms of pre and post conditions.

We codified this pre-condition / post-condition specification in terms
of events and event handlers.

Now, from the scripting context  --especially in thinking of it in a
runtime like Mozilla --you may well be right that there may be more
granularity in the events as specified than you might perhaps need in
scripting inside Mozilla--
However, this granularity might also be key to implementing a
distributed XForms processor where not all stages of processing live
on the same point of the network.>>>>> "John" == 


In summary,  the events  such  as model-initialize and friends are
there to specify the processing model declaratively.

With respect to DOM3 events we clearly couldn't depend on something
that wasn't out there yet  as a W3C final CR --which is why we chose
to create a set of abstract event types in the XForms namespace.

As with XPath 2.0, we will probably use DOM 3.0 in XForms 2.0 --wel,
that is once we wind up 1.0.



John Keiser <jkeiser@netscape.com> writes:

    John> Greetings, I have been reading the XForms 1.0 draft. It does
    John> most of what it set out to do (an amazing accomplishment):
    John> it fixes forms, and adds adds a lot of important stuff to
    John> the picture. But I am concerned that it has some real
    John> problems that will significantly slow its adoption among web
    John> developers.

    John> The major sections of the XForms Requirements that I think
    John> the spec does not completely fulfill are 2.3 (Migration from
    John> HTML 4), 2.4 (Ease of Authoring), and 2.7 (Scripting
    John> Interfaces). This is due largely to an oversaturation of
    John> events, lack of adequate facilities for scripting
    John> (interfaces and hooks for scripting to start, and much of
    John> the "action" model being better suited to true scripting
    John> languages), and general emphasis on elements rather than
    John> attributes.

    John> My interest here is not idle. First, I am the primary
    John> maintainer of the form implementation in Mozilla/Netscape,
    John> and I am acutely aware of many of its flaws (most of which
    John> XForms remedies). Second, I am interested in implementing
    John> XForms in Mozilla/Netscape, and I want to make sure that
    John> what I implement will not frustrate the web developers the
    John> browser supports :) But if things are open to change even
    John> after CR, which it seems it is, then I'm glad to jump into
    John> the fray and implement in parallel with the changing
    John> process. I wish I could have gotten involved in the process
    John> earlier, but I only began working on Mozilla less than a
    John> year ago.

    John> Some of the suggested changes here may seem a little extreme
    John> (it removes a lot of events and actions), but my feeling is,
    John> start small and build up after the first release. As my
    John> grandmother said of cooking, "you can always put more
    John> ingredients in, but you can't take them back out."


    John> WHAT I LIKE

    John> 1. Separating form control layout from the model fixes a
    John> major problem in forms: the unnecessary requirement for
    John> controls to be contained in the <form> tag.

    John> 2. Making it possible for the server to validate using the
    John> same rules as the client is huge.

    John> 3. Allowing instance data to be carried across pages is a
    John> huge win. The mechanism to do this is not very well
    John> addressed here, but I don't feel itshould be addressed here.
    John> It is entirely a presentation issue, unless you actually
    John> want to be able to access the same instance data across
    John> documents. It could be handled in XHTML, for example, with a
    John> <wizard> or <tab> element. Daniel Glazman tells me the
    John> :target selector may help with this.

    John> 4. The addition of an editable combobox will make data entry
    John> developers drool.

    John> 5. The spreadsheet idea is really cool. Computational
    John> dependencies are going to be a really difficult point,
    John> however, as discussed in #12 in the next section.

    John> 6. The ability to submit arbitrary XML is a real boon,
    John> enabling SOAP apps to take data from a form, which was
    John> probably part of the intent :)

    John> 7. The whole hint / help thing is pretty cool. I like the
    John> ability to easily specify help for various
    John> controls--something that different apps have been doing
    John> differently (or not at all) since time immemorial.


    John> MY CONCERNS

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

    John> - [4.2]: xforms-model-construct and friends: is there a
    John> benefit to having these 5 stages of initialization being
    John> transparent to the web developer? Perhaps some of these
    John> could go away, such as xforms-model-construct,
    John> xforms-model-initialize-done and xforms-ui-initialize? -
    John> [4.3.1]: next and prev can be useful for a control to stop
    John> focus from being changed, but how about coalescing them into
    John> xforms-focus -out to handle other things like the user
    John> trying to click on another element? This also means they
    John> won't do next and forget prev. I am a little dubious about
    John> the usefulness of this overall given that we have
    John> value-changed already, but implementation stage will tell. -
    John> [4.3.2]: why do you need this and xforms-unfocus when you
    John> have calculatable readonly and disabled properties? -
    John> [4.3.4]: xforms-refresh: if all form controls are required
    John> to represent the value in the instance data at all times, as
    John> [8.1.1] seems to say, how can this be anything but a no-op?
    John> If it is supposed to be in response to when a particular
    John> piece of instance data is modified in the DOM, shouldn't
    John> that be handled by the form controls listening for changes?
    John> - [4.3.5, 4.3.6]: xforms-revalidate, xforms-recalculate: do
    John> we *really* need these? Does script need to catch them? I
    John> can see potential uses hanging at the edge of my intuition,
    John> so perhaps :) - [4.3.7] xforms-rebuild: we definitely don't
    John> need to catch this event in script. I can see the last two,
    John> but not this one. - [4.4.1] xforms-activate -> DOMActivate.
    John> From DOM3 Events spec, "The activate event occurs when an
    John> element's default action is activated, for instance, thru a
    John> MouseEvent
    John> <http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-MouseEvent>
    John> click or a TextEvent
    John> <http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-TextEvent>
    John> textInput." From XForms 1.0, "Dispatched in response to: the
    John> "default action request" for a form control, for instance
    John> pressing a button or hitting enter." They read the same to
    John> me. - [4.4.5]: xforms-scroll-(first|last): I am concerned
    John> about this but I haven't built a good enough repeat model in
    John> my head to determine if I like them or not. - [4.4.11-16]:
    John> xforms-readonly, -readwrite, -disabled, etc. should only be
    John> fired when the state changes. If that is granted, then they
    John> can just be handled with DOM mutation events (perhaps these
    John> are too hard?). If that is not granted, at the least
    John> readonly/readwrite could be readonly-changed,
    John> disabled/enabled could be disabled-changed, etc. Still I
    John> recommend removal altogether until a significant need is
    John> shown.

    John> SUGGESTED CHANGES: - Remove xforms-model-construct,
    John> xforms-model-initialize, xforms-ui-initialize. - Replace
    John> xforms-next and xforms-prev with xforms-focus-out - Remove
    John> xforms-focus. (readonly and disabled are sufficient to
    John> prevent focus from changing into a control.) - Remove
    John> xforms-refresh and xforms-rebuild. - Rename xforms-activate
    John> to DOMActivate. - Remove xforms-readonly, xforms-readwrite,
    John> xforms-disabled, xforms-enabled, xforms-required and
    John> xforms-optional

    John> 2. [9.2.1] <switch> is a layout-oriented (it seems to be
    John> used to specify a "wizard" interface or split things up for
    John> a PDA, or to specify a set of layout stuff that will appear
    John> only if a particular expression is true). It belongs in a
    John> layout-oriented spec such as SVG or XHTML.

    John> SUGGESTED CHANGES: - Remove <switch> / <case>

    John> 3. The syntax is generally too element-oriented and does not
    John> allow attributes in enough places; [8.1.10] <select*> is
    John> particularly bad about that. This makes it hard to write.
    John> [8.3.3] "label" in particular needs to be specifiable as an
    John> attribute (like <trigger label="Click here">). It's too
    John> commonly used to require the bulky element syntax. This will
    John> make things more readable and easier to write.

    John> SUGGESTED CHANGES: - Allow "label" and "hint" as an
    John> attribute on all form controls (perhaps say "elements take
    John> precedence over attributes where there is a conflict") -
    John> Allow "value" as an attribute in <item>

    John> 4. [10] actions look like an attempt to define yet another
    John> (very) basic scripting language in XML. Why, when other
    John> scripting languages already exist? I can see the need for
    John> the most common of these actions, but I think only the most
    John> common ones that would be done in a <trigger>--send, reset,
    John> and some sort of script (unless there is an easy way to
    John> specify event handlers in XForms / XML without resorting to
    John> a JavaScript onLoad handler?). Let uncommon actions be done
    John> in script--we don't need two versions of every function, and
    John> all functionality needs to be in a DOM, so <action> is the
    John> one where we should be parsimonious. I hear the rule of
    John> thumb in the WG is 80%/20% ... that's an admirable goal, but
    John> I doubt 80% of it can be dealt with, period. Many buttons
    John> are just too custom. A more reasonable goal is "the most
    John> common functions people will expect to have in the browser."
    John> This includes reset and submit by default (to migrate from
    John> HTML), and probably includes insert and delete. script can
    John> handle the rest.

    John> SUGGESTED CHANGES: - Remove all actions but submitInstance,
    John> resetInstance, insert, delete, and script. Note that other
    John> actions may be common enough to meet the threshold--this is
    John> just my gut feeling of the most common actions for a
    John> <trigger>.

    John> 5. [8.1.4] textarea doesn't seem to have attributes for
    John> columns/rows (perhaps this is a CSS thing) ... a question
    John> that needs to be asked is whether we need wrap="hard" in
    John> textarea, which affects both layout and data. Also, textarea
    John> should also be able to encompass both single-line and
    John> multiline text controls for people who really just want a
    John> text control for input rather than a general "who knows what
    John> you'll get" <input>. I must say, also, that I am a little
    John> concerned about <textarea> having to reflect the current
    John> value in the instance data at all times. Given the way soft
    John> wrapping works, a proper implementation is going to have to
    John> do a somewhat expensive operation (O(n) where n is the
    John> number of lines in the control--and a string copy) on every
    John> keystroke. We can work this out as time goes by,
    John> though--perhaps for <textarea> the instance data isn't
    John> required to get updated immediately on every keystroke, but
    John> only when value-changing occurs.

    John> SUGGESTED CHANGES: - Add a "wrap" attribute specifying that
    John> the current value in the instance data should contain the
    John> carriage returns in the textarea. This could be easily saved
    John> until the next version, as it is an addition.

    John> 6. Putting xforms controls into the xforms namespace and not
    John> providing for the vast majority of form developers who are
    John> going to be doing all this within an xhtml layout seems bad
    John> to me. We need to place the new controls in the xhtml
    John> namespace. Peppering their layout code (for that is truly
    John> what the form controls themselves are--specifiers indicating
    John> presentation and UI on top of some data) with "xforms:" or
    John> even "f:" is going to be a turnoff for developers. This is a
    John> minor point, though, and can be addressed in XML itself by
    John> supporting multiple default namespaces with DTDs. I
    John> understand somewhat the desire to keep it out of xhtml
    John> namespace, if this is useful in SVG.

    John> SUGGESTED CHANGES: - None. I have heard the XHTML WG is
    John> considering a way to handle it. We'll look and see.

    John> 7. I don't see any scripting interface here. Perhaps this is
    John> bound up in the decision to have such a rich action model,
    John> or perhaps there is a planned XForms DOM? [7.2]
    John> (http://www.w3.org/TR/xforms/slice7.html#expr-instance) is
    John> missing method names, but what it even shows there does not
    John> handle everything it needs to. Particularly, everything that
    John> is currently in an action needs to be do-able in script.

    John> SUGGESTED CHANGES: - Create a full-featured DOM (this is too
    John> big a task for me to specify completely here, but at the
    John> minimum most of the stuff that is currently in <action> tags
    John> should be do-able via a DOM interface somewhere).
    John> submitInstance(), resetInstance(), insert() and delete()
    John> need to be there at the least.

    John> 8. [8.3.4] help is overspecified. If an implementor wants to
    John> have a "help window" section that displays help text, they
    John> should be able to.

    John> SUGGESTED CHANGES: - Don't say anything about how help is
    John> implemented in a user agent.

    John> 9. [Appendix D] Jonas Sicking <sicking@bigfoot.com> has
    John> pointed out to me that there are many very basic cases that
    John> you cannot form a real non-circular dependency tree--many
    John> XPath functions deal with nodesets that "depend" on the
    John> entire tree ("average of all valid numeric descendants of
    John> element root"), thus making any other dependency but that
    John> one create a circle. You could recalculate dependencies
    John> every time you recalculate for these cases, though, and
    John> alleviate that problem. Further, XPath selectors can select
    John> nodes where attribute=<specific
    value> , which makes their dependency continuously change over
    value> time, even
    John> during the calculation stage. Dependencies would have to, in
    John> that case, be recalculated after each calculation step, and
    John> choosing which nodes to calculate first would be a rather
    John> complex process.

    John> SUGGESTED CHANGES: - this is more of a concern than an issue
    John> requiring resolution. I suspect during implementation in
    John> Mozilla (which has a lot of XPath in it) we will know better
    John> whether and how it will fully work.

    John> Regarding the XML Schema dependency: I hear that XML Schema
    John> is "bloated" and wanted to say that I just plain don't have
    John> enough experience with XML Schemas to know, so I haven't
    John> commented on it. I am glad that XForms removed the plethora
    John> of XML Schema-inspired date types that were in the earlier
    John> version of the spec, however.


    John> Thanks to everybody involved for XForms. I hope this is
    John> taken in the spirit in which it was intended: to help make
    John> things better. I would very much like XForms to succeed and
    John> be something web developers consciously choose. Let <form>
    John> go to its grave :)

    John> Cheers,

    John> John Keiser Netscape Forms Developer <!DOCTYPE html PUBLIC
    John> "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head>
    John> <meta http-equiv="Content-Type"
    John> content="text/html;charset=ISO-8859-1"> <title></title>
    John> </head> <body> Greetings,<br> <br> I have been reading the
    John> XForms 1.0 draft. &nbsp;It does most of what it set out to
    John> do (an amazing accomplishment): it fixes forms, and adds
    John> adds a lot of important stuff to the picture. &nbsp;But I am
    John> concerned that it has some real problems that will
    John> significantly slow its adoption among web developers.<br>
    John> <br> The major sections of the XForms Requirements that I
    John> think the spec does not completely fulfill are 2.3
    John> (Migration from HTML 4), 2.4 (Ease of Authoring), and 2.7
    John> (Scripting Interfaces). &nbsp;This is due largely to an
    John> oversaturation of events, lack of adequate facilities for
    John> scripting (interfaces and hooks for scripting to start, and
    John> much of the "action" model being better suited to true
    John> scripting languages), and general emphasis on elements
    John> rather than attributes.<br> <br> My interest here is not
    John> idle. &nbsp;First, I am the primary maintainer of the form
    John> implementation in Mozilla/Netscape, and I am acutely aware
    John> of many of its flaws (most of which XForms remedies).
    John> &nbsp;Second, I am interested in implementing XForms in
    John> Mozilla/Netscape, and I want to make sure that what I
    John> implement will not frustrate the web developers the browser
    John> supports :) &nbsp;But if things are open to change even
    John> after CR, which it seems it is, then I'm glad to jump into
    John> the fray and implement in parallel with the changing
    John> process. &nbsp;I wish I could have gotten involved in the
    John> process earlier, but I only began working on Mozilla less
    John> than a year ago.<br> <br> Some of the suggested changes here
    John> may seem a little extreme (it removes a lot of events and
    John> actions), but my feeling is, start small and build up after
    John> the first release. &nbsp;As my grandmother said of cooking,
    John> "you can always put more ingredients in, but you can't take
    John> them back out."<br> <br> <br> WHAT I LIKE<br> <br> 1.
    John> Separating form control layout from the model fixes a major
    John> problem in forms: the unnecessary requirement for controls
    John> to be contained in the &lt;form&gt; tag.<br> <br> 2. Making
    John> it possible for the server to validate using the same rules
    John> as the client is <i>huge.</i><br> <br> 3. Allowing instance
    John> data to be carried across pages is a huge win. &nbsp;The
    John> mechanism to do this is not very well addressed here, but I
    John> don't feel it<i>should</i> be addressed here. &nbsp;It is
    John> entirely a presentation issue, unless you actually want to
    John> be able to access the same instance data across
    John> <i>documents.</i> &nbsp;It could be handled in XHTML, for
    John> example, with a &lt;wizard&gt; or &lt;tab&gt; element.
    John> &nbsp;Daniel Glazman tells me the :target selector may help
    John> with this.<br> <br> 4. The addition of an editable combobox
    John> will make data entry developers drool.<br> <br> 5. The
    John> spreadsheet idea is really cool. &nbsp;Computational
    John> dependencies are going to be a really difficult point,
    John> however, as discussed in #12 in the next section.<br> <br>
    John> 6. The ability to submit arbitrary XML is a real boon,
    John> enabling SOAP apps to take data from a form, which was
    John> probably part of the intent :)<br> <br> 7. The whole hint /
    John> help thing is pretty cool. &nbsp;I like the ability to
    John> easily specify help for various controls--something that
    John> different apps have been doing differently (or not at all)
    John> since time immemorial.<br> <br> <br> MY CONCERNS<br> <br> 1.
    John> There is a huge number of events in the system that adds
    John> more confusion than it helps. &nbsp;Some of these events,
    John> such as xforms-activate and even to an extent value-changed
    John> (mutation events), duplicate functionality in the DOM3
    John> Events module. &nbsp;Others seem unnecessary or redundant.
    John> &nbsp;Events do not exist to expose every single step of an
    John> implementor's algorithm. &nbsp;Events are meant to be useful
    John> hooks for scripts. &nbsp;This seems like a good rule: "don't
    John> add an event unless somebody can think of a good conceivable
    John> use for it." &nbsp;Please also remember that mutation events
    John> targeted at the instance data should take care of even more
    John> things than this spec takes care of.<br> <br> - [4.2]:
    John> xforms-model-construct and friends: is there a benefit to
    John> having these 5 stages of initialization being transparent to
    John> the web developer? &nbsp;Perhaps some of these could go
    John> away, such as xforms-model-construct,
    John> xforms-model-initialize-done and xforms-ui-initialize?<br> -
    John> [4.3.1]: next and prev can be useful for a control to stop
    John> focus from being changed, but how about coalescing them into
    John> xforms-focus -out to handle other things like the user
    John> trying to click on another element? &nbsp;This also means
    John> they won't do next and forget prev. &nbsp;I am a little
    John> dubious about the usefulness of this overall given that we
    John> have value-changed already, but implementation stage will
    John> tell.<br> - [4.3.2]: why do you need this and xforms-unfocus
    John> when you have calculatable readonly and disabled
    John> properties?<br> - [4.3.4]: xforms-refresh: if all form
    John> controls are required to represent the value in the instance
    John> data at all times, as [8.1.1] seems to say, how can this be
    John> anything but a no-op? &nbsp;If it is supposed to be in
    John> response to when a particular piece of instance data is
    John> modified in the DOM, shouldn't that be handled by the form
    John> controls listening for changes?<br> - [4.3.5, 4.3.6]:
    John> xforms-revalidate, xforms-recalculate: do we *really* need
    John> these? &nbsp;Does script need to catch them? &nbsp;I can see
    John> potential uses hanging at the edge of my intuition, so
    John> perhaps :)<br> - [4.3.7] xforms-rebuild: we definitely don't
    John> need to catch this event in script. &nbsp;I can see the last
    John> two, but not this one.<br> - [4.4.1] xforms-activate -&gt;
    John> DOMActivate. &nbsp;From DOM3 Events spec, "The activate
    John> event occurs when an element's default action is activated,
    John> for instance, thru a <a
    John> href="http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-MouseEvent"><code>MouseEvent</code></a>
    John> click or a <a
    John> href="http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/events.html#Events-TextEvent"><code>TextEvent</code></a>
    John> textInput." &nbsp;From XForms 1.0, "Dispatched in response
    John> to: the "default action request" for a form control, for
    John> instance pressing a button or hitting enter." &nbsp;They
    John> read the same to me.<br> - [4.4.5]:
    John> xforms-scroll-(first|last): I am concerned about this but I
    John> haven't built a good enough repeat model in my head to
    John> determine if I like them or not.<br> - [4.4.11-16]:
    John> xforms-readonly, -readwrite, -disabled, etc. should only be
    John> fired when the state <i>changes.</i> &nbsp;If that is
    John> granted, then they can just be handled with DOM mutation
    John> events (perhaps these are too hard?). &nbsp;If that is not
    John> granted, at the least readonly/readwrite could be
    John> readonly-changed, disabled/enabled could be
    John> disabled-changed, etc. &nbsp;Still I recommend removal
    John> altogether until a significant need is shown.<br> <br>
    John> SUGGESTED CHANGES:<br> - Remove xforms-model-construct,
    John> xforms-model-initialize, xforms-ui-initialize.<br> - Replace
    John> xforms-next and xforms-prev with xforms-focus-out<br> -
    John> Remove xforms-focus. &nbsp;(readonly and disabled are
    John> sufficient to prevent focus from changing <i>into</i> a
    John> control.)<br> - Remove xforms-refresh and
    John> xforms-rebuild.<br> - Rename xforms-activate to
    John> DOMActivate.<br> - Remove xforms-readonly, xforms-readwrite,
    John> xforms-disabled, xforms-enabled, xforms-required and
    John> xforms-optional<br> <br> 2. [9.2.1] &lt;switch&gt; is a
    John> layout-oriented (it seems to be used to specify a "wizard"
    John> interface or split things up for a PDA, or to specify a set
    John> of layout stuff that will appear only if a particular
    John> expression is true). &nbsp;It belongs in a layout-oriented
    John> spec such as SVG or XHTML.<br> <br> SUGGESTED CHANGES:<br> -
    John> Remove &lt;switch&gt; / &lt;case&gt;<br> <br> 3. The syntax
    John> is generally too element-oriented and does not allow
    John> attributes in enough places; [8.1.10] &lt;select*&gt; is
    John> particularly bad about that. &nbsp;This makes it hard to
    John> write. &nbsp;[8.3.3] "label" in particular needs to be
    John> specifiable as an attribute (like &lt;trigger label="Click
    John> here"&gt;). &nbsp;It's too commonly used to require the
    John> bulky element syntax. &nbsp;This will make things more
    John> readable and easier to write.<br> <br> SUGGESTED
    John> CHANGES:<br> - Allow "label" and "hint"&nbsp; as an
    John> attribute on all form controls (perhaps say "elements take
    John> precedence over attributes where there is a conflict")<br> -
    John> Allow "value" as an attribute in &lt;item&gt;<br> <br> 4.
    John> [10] actions look like an attempt to define yet another
    John> (very) basic scripting language in XML. &nbsp;Why, when
    John> other scripting languages already exist? &nbsp;I can see the
    John> need for the most common of these actions, but I think only
    John> the most common ones that would be done in a
    John> &lt;trigger&gt;--send, reset, and some sort of script
    John> (unless there is an easy way to specify event handlers in
    John> XForms / XML without resorting to a JavaScript onLoad
    John> handler?). &nbsp;Let uncommon actions be done in script--we
    John> don't need two versions of every function, and all
    John> functionality needs to be in a DOM, so &lt;action&gt; is the
    John> one where we should be parsimonious. &nbsp;I hear the rule
    John> of thumb in the WG is 80%/20% ... that's an admirable goal,
    John> but I doubt 80% of it <i>can</i> be dealt with, period.
    John> &nbsp;Many buttons are just too custom. &nbsp;A more
    John> reasonable goal is "the most common functions people will
    John> expect to have in the browser." &nbsp;This includes reset
    John> and submit by default (to migrate from HTML), and probably
    John> includes insert and delete. &nbsp;script can handle the
    John> rest.<br> <br> SUGGESTED CHANGES:<br> - Remove all actions
    John> but submitInstance, resetInstance, insert, delete, and
    John> script. &nbsp;Note that other actions may be common enough
    John> to meet the threshold--this is just my gut feeling of the
    John> most common actions for a &lt;trigger&gt;.<br> <br> 5.
    John> [8.1.4] textarea doesn't seem to have attributes for
    John> columns/rows (perhaps this is a CSS thing) ... a question
    John> that needs to be asked is whether we need wrap="hard" in
    John> textarea, which affects <i>both</i> layout and data.
    John> &nbsp;Also, textarea should also be able to encompass both
    John> single-line and multiline text controls for people who
    John> really just want a text control for input rather than a
    John> general "who knows what you'll get" &lt;input&gt;. &nbsp;I
    John> must say, also, that I am a little concerned about
    John> &lt;textarea&gt; having to reflect the current value in the
    John> instance data at all times. &nbsp;Given the way soft
    John> wrapping works, a proper implementation is going to have to
    John> do a somewhat expensive operation (O(n) where n is the
    John> number of lines in the control--and a string copy) on every
    John> keystroke. &nbsp;We can work this out as time goes by,
    John> though--perhaps for &lt;textarea&gt; the instance data isn't
    John> required to get updated immediately on every keystroke, but
    John> only when value-changing occurs.<br> <br> SUGGESTED
    John> CHANGES:<br> - Add a "wrap" attribute specifying that the
    John> current value in the instance data should contain the
    John> carriage returns in the textarea. &nbsp;This could be easily
    John> saved until the next version, as it is an addition.<br> <br>
    John> 6. Putting xforms controls into the xforms namespace and not
    John> providing for the vast majority of form developers who are
    John> going to be doing all this within an xhtml layout seems bad
    John> to me. &nbsp;We need to place the new controls in the xhtml
    John> namespace. &nbsp;Peppering their layout code (for that is
    John> truly what the form controls themselves are--specifiers
    John> indicating presentation and UI on top of some data) with
    John> "xforms:" or even "f:" is going to be a turnoff for
    John> developers. &nbsp;This is a minor point, though, and can be
    John> addressed in XML itself by supporting multiple default
    John> namespaces with DTDs. &nbsp;I understand somewhat the desire
    John> to keep it out of xhtml namespace, if this is useful in
    John> SVG.<br> <br> SUGGESTED CHANGES:<br> - None. &nbsp;I have
    John> heard the XHTML WG is considering a way to handle it.
    John> &nbsp;We'll look and see.<br> <br> 7. I don't see any
    John> scripting interface here. &nbsp;Perhaps this is bound up in
    John> the decision to have such a rich action model, or perhaps
    John> there is a planned XForms DOM? &nbsp;[7.2]
    John> (<a>http://www.w3.org/TR/xforms/slice7.html#expr-instance</a>)
    John> is missing method names, but what it even shows there does
    John> not handle everything it needs to. &nbsp;Particularly,
    John> everything that is currently in an action needs to be
    John> do-able in script.<br> <br> SUGGESTED CHANGES:<br> - Create
    John> a full-featured DOM (this is too big a task for me to
    John> specify completely here, but at the minimum most of the
    John> stuff that is currently in &lt;action&gt; tags should be
    John> do-able via a DOM interface somewhere).
    John> &nbsp;submitInstance(), resetInstance(), insert() and
    John> delete() need to be there at the least.<br> <br> 8. [8.3.4]
    John> help is overspecified. &nbsp;If an implementor wants to have
    John> a "help window" section that displays help text, they should
    John> be able to.<br> <br> SUGGESTED CHANGES:<br> - Don't say
    John> anything about how help is implemented in a user agent.<br>
    John> <br> 9. [Appendix D] Jonas Sicking
    John> <a>&lt;sicking@bigfoot.com&gt;</a> has pointed out to me
    John> that there are many very basic cases that you cannot form a
    John> real non-circular dependency tree--many XPath functions deal
    John> with nodesets that "depend" on the entire tree ("average of
    John> all valid numeric descendants of element root"), thus making
    John> any other dependency but that one create a circle. &nbsp;You
    John> could recalculate dependencies every time you recalculate
    John> for these cases, though, and alleviate that problem.
    John> &nbsp;Further, XPath selectors can select nodes where
    John> attribute=&lt;specific value&gt;, which makes their
    John> dependency continuously change over time, even during the
    John> calculation stage. &nbsp;Dependencies would have to, in that
    John> case, be recalculated after each calculation step, and
    John> choosing which nodes to calculate first would be a rather
    John> complex process.<br> <br> SUGGESTED CHANGES:<br> - this is
    John> more of a concern than an issue requiring resolution.
    John> &nbsp;I suspect during implementation in Mozilla (which has
    John> a lot of XPath in it) we will know better whether and how it
    John> will fully work.<br> <br> Regarding the XML Schema
    John> dependency: I hear that XML Schema is "bloated" and wanted
    John> to say that I just plain don't have enough experience with
    John> XML Schemas to know, so I haven't commented on it. &nbsp;I
    John> am glad that XForms removed the plethora of XML
    John> Schema-inspired date types that were in the earlier version
    John> of the spec, however.<br> <br> <br> Thanks to everybody
    John> involved for XForms. &nbsp;I hope this is taken in the
    John> spirit in which it was intended: to help make things better.
    John> &nbsp;I would very much like XForms to succeed and be
    John> something web developers consciously choose. &nbsp;Let
    John> &lt;form&gt; go to its grave :)<br> <i></i><br> Cheers,<br>
    John> <br> John Keiser<br> Netscape Forms Developer<br> </body>
    John> </html>

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
Architect:    Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608   T-Line 457-2608
Fax:        1 (408) 927 3012     Cell: 1 650 799 5724
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
AIM:      TVRaman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120
Received on Thursday, 5 September 2002 19:43:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:52 GMT