- From: Dan Dennedy <DDennedy@digitalbang.com>
- Date: Mon, 9 Sep 2002 09:47:25 -0400
- 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>
- Message-ID: <11DC9B322580C843AE5A3D030D950B03031A6E@intrabang01.digitalbang.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, John
Received on Monday, 9 September 2002 09:48:11 UTC