- From: T. V. Raman <tvraman@us.ibm.com>
- Date: Thu, 5 Sep 2002 16:41:33 -0700
- 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. 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. 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). 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. 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> 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 :) 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
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. 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 <form> 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. 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. 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> It could be handled in XHTML, for
John> example, with a <wizard> or <tab> element.
John> 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. 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. 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. 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. Others seem unnecessary or redundant.
John> Events do not exist to expose every single step of an
John> implementor's algorithm. Events are meant to be useful
John> hooks for scripts. This seems like a good rule: "don't
John> add an event unless somebody can think of a good conceivable
John> use for it." 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? 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? This also means
John> they won't do next and forget prev. 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? 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? Does script need to catch them? 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. I can see the last
John> two, but not this one.<br> - [4.4.1] xforms-activate ->
John> DOMActivate. 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." 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." 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> If that is
John> granted, then they can just be handled with DOM mutation
John> events (perhaps these are too hard?). If that is not
John> granted, at the least readonly/readwrite could be
John> readonly-changed, disabled/enabled could be
John> disabled-changed, etc. 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. (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] <switch> 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). It belongs in a layout-oriented
John> spec such as SVG or XHTML.<br> <br> SUGGESTED CHANGES:<br> -
John> Remove <switch> / <case><br> <br> 3. The syntax
John> is generally too element-oriented and does not allow
John> attributes in enough places; [8.1.10] <select*> is
John> particularly bad about that. This makes it hard to
John> write. [8.3.3] "label" in particular needs to be
John> specifiable as an attribute (like <trigger label="Click
John> here">). It's too commonly used to require the
John> bulky element syntax. This will make things more
John> readable and easier to write.<br> <br> SUGGESTED
John> CHANGES:<br> - 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")<br> -
John> Allow "value" as an attribute in <item><br> <br> 4.
John> [10] actions look like an attempt to define yet another
John> (very) basic scripting language in XML. Why, when
John> other scripting languages already exist? 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> <trigger>--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?). 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 <action> is the
John> one where we should be parsimonious. 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> Many buttons are just too custom. A more
John> reasonable goal is "the most common functions people will
John> expect to have in the browser." This includes reset
John> and submit by default (to migrate from HTML), and probably
John> includes insert and delete. script can handle the
John> rest.<br> <br> SUGGESTED CHANGES:<br> - Remove all actions
John> but submitInstance, resetInstance, insert, delete, and
John> script. 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 <trigger>.<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> 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" <input>. I
John> must say, also, that I am a little concerned about
John> <textarea> having to reflect the current value in the
John> 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.<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. 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. We need to place the new controls in the xhtml
John> namespace. 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. This is a minor point, though, and can be
John> addressed in XML itself by supporting multiple default
John> namespaces with DTDs. 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. I have
John> heard the XHTML WG is considering a way to handle it.
John> We'll look and see.<br> <br> 7. I don't see any
John> scripting interface here. 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? [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. 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 <action> tags should be
John> do-able via a DOM interface somewhere).
John> submitInstance(), resetInstance(), insert() and
John> delete() need to be there at the least.<br> <br> 8. [8.3.4]
John> help is overspecified. 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><sicking@bigfoot.com></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. You
John> could recalculate dependencies every time you recalculate
John> for these cases, though, and alleviate that problem.
John> Further, XPath selectors can select nodes where
John> attribute=<specific value>, which makes their
John> dependency continuously change over time, even during the
John> calculation stage. 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> 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. 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. I hope this is taken in the
John> spirit in which it was intended: to help make things better.
John> I would very much like XForms to succeed and be
John> something web developers consciously choose. Let
John> <form> 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 UTC