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

Spec comments

From: Alex Rosen <arosen@novell.com>
Date: Tue, 08 Oct 2002 07:30:51 -0600
Message-Id: <sda297df.066@prv-mail20.provo.novell.com>
To: <www-forms@w3.org>

Here are some comments that I have regarding the 8/21 XForms spec, after
wrestling with it for a month. Hope they are helpful.

Alex Rosen
Novell, Inc.


It seems obvious in retrospect, but I initially had no idea why you'd
want to put actions in the model, since I'm still getting used to the
XML Events mechanism. Adding something like "... for example to handle
events that occur on the model" would be nice.


<submission replace="all'> is confusing -  "replace" sounds like it's
telling the server what to do with the instance data that we're sending,
like replace the previous values or something. Every other submission
attribute describes how to send the data to the server, but this one is
different, it describes what to do with the server's response. Something
like "response-action" would be more immediately obvious.


"default processing" is not defined here. It presumably is refering to
the "default action" in the XML Events spec, but even if the names
matched this is not clear to those of us who are not that familiar with
XML Events. A pointer to that spec for the definition of default
processing would help. I also think that XML Events spec is very unclear
in this area. A brief explanation of what "default processing" means,
and when conceptually it takes place, would be helpful. E.g. here are my
guesses at the details that I think are missing from the XML Events

 - The default processing/action takes place after the capture phase,
and before the bubble or target phase.
 - Therefore, you can prevent the default processing from occurring in
the capture phase, and you can react to the results of the default
processing in the bubble or target phase.
 - If the event doesn't bubble, then it has a target phase instead of a
bubble phase, the only difference being that the only observer that's
notified in the target phase is the target object.
 - An event might not have a bubble phase because... why?
 - If you stop propogation of an event during the capture phase, then
the default processing doesn't take place, but in the bubble or target
phase it's too late. If you cancel the default action in the capture
phase of the target object, then the default processing doesn't take
place, but anywhere else this has no effect, including in the capture
phase of any ancestors of the target. (Why is that? Or maybe in XML
Events there can be a default action at each point in the chain, but in
the example there's only a default action that takes place on the <a>
element? Not clear to me.)


"that is used instead" - slightly unclear - sounds kind of like you
might be saying that the inline instance is used as the XPath data
model. Should clarify that you mean that the XPath data model is
constructed from the inline instance.


How is the XPath data model constructed from the instance data in the
previous step, if the instance data hasn't been created until just now?

Also, should say that step 2 is skipped if no instance data is
specified in the model node.


It took a close reading of this section of the spec to realize that
most XForms should have initial instance data. Several of us did not
think this at first - we thought that XForms provided a nice mechanism
for creating the initial instance data from the XPaths, so why bother? I
actually assumed that QName in step 1B really meant LocationPath, or
some subset of LocationPath, because otherwise (1) you could only refer
to the root element, which was useless, and (2) you couldn't create even
moderately complex documents with nested elements. It had to be
explained to me that (1) the context node at this point is the root
element, so a QName will actually refer to a child of the root element,
and (2) this entire process was actually intended for
backward-compatibility, to be used along with
application/x-www-form-urlencoded, to work with existing servlets etc.
that will process the data, and (3) because of this, it is intended that
a XForm should always contain initial instance data, except when used in
this backwards-compatible way. Mentioning these things explicitly would
provide the kind of background rationale can sometimes save a lot of
head scratching.


Before xforms-ui-initialize, this seems to say that you don't have to
do step 3 - does that imply that you have to do the other two steps? I
don't think they have any effect without step 3, so I assume not, but it
should be more clear.


Should make it clear whether the text that gets output should be
interpreted as markup - e.g. if you're using XHTML and it outputs the
text "<a href=...>" should it create a link, not create a link, or is it
up to the implementation?


"Required XPath expression evaluated to determine insert location." -
copy/paste error, this is delete not insert.


xmlns:xsd is needlessly defined in this example.


xmlns:my and xmlns:xsd are needlessly defined in this example.

Lastly, I have to agree with John Keiser, near the top of
http://lists.w3.org/Archives/Public/www-forms/2002Sep/0196.html. The
large number of very similar events is very confusing. Specifically I'm
talking about all the initialize events, and the
refresh/rebuild/revalidate/recalculate events, which I can never keep
straight. What good is the rebuild event to the user, and how do we
explain the difference between it and recalculate?
Received on Tuesday, 8 October 2002 09:32:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:07 UTC