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

RE: XForms 1.0: My Opinions

From: Dan Dennedy <DDennedy@digitalbang.com>
Date: Mon, 9 Sep 2002 09:47:25 -0400
Message-ID: <11DC9B322580C843AE5A3D030D950B03031A6E@intrabang01.digitalbang.com>
To: "John Keiser" <jkeiser@netscape.com>, "Mikko Honkala" <honkkis@tml.hut.fi>
Cc: <www-forms@w3.org>, "Beth Epperson" <beppe@netscape.com>, "Daniel Glazman" <glazman@netscape.com>


			I'm not convinced on the point of <setValue> but
if a significant portion of forms are going to use it then it's fine (I
have a feeling they will not, but it remains to be seen).  There is DOM
access to XPath too.

		I have used setValue in most of the demos I've created,
so I do not agree. It has proven a quite powerful function of XForms,
and I doubt that XForms would be the same without it.

	I bow to your experience.  I will withhold personal judgement on
this for now, until I have had more experience with JavaScript-enabled
XForms :)  

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

				I don't completely agree. It just
defines that the help is similar that a modeless message, which is not
too tightly specified in 10.1.12.

			It actually says it has to be the /same/ as a
modeless message, not just similar.  modeless message could be a
suggested implementation, but I don't think there should be any
constraints.  Let's let the browser implementor put help in a special
help space if they want, even if modeless messages happen in popup
windows.  Let them experiment.

		It could help UI interoperability to have at least some
rules here.

	IMHO, rules should be made abstract, however; for example "help
should be more obvious, more 'in the user's face' than a hint" rather
than "help should always be rendered the same as this other UI construct
we have created."  This is overall a minor point, however. 

				9. [Appendix D] Jonas Sicking
<sicking@bigfoot.com> <mailto:sicking@bigfoot.com>  has pointed out to
me that there are many very basic cases that you cannot form a real
non-circular dependency tree--many XPath functions deal with nodesets
that "depend" on the entire tree ("average of all valid numeric
descendants of element root"), 

				IMHO a form author can always construct
the instance data so that you don't have to write functions that depend
on the entire tree, so I don't consider this a real problem.

			A form author can't always construct the
instance data the way he wants :)  One of the major applications I see
for this is XML interoperability and SOAP, which means your data format
is fixed by the person you are sending data /to./

		By the way, does it help your use case that XForms
deliberately allows self-reference in XPath calculations (see app. D)?

	I am going to have to punt to Jonas on this for now.  He does
have a better feel for this than me.  I think he's planning to write up
his concerns on the dependency model to the list.
	Many happy returns,
Received on Monday, 9 September 2002 09:48:11 UTC

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