- From: T. V. Raman <tvraman@almaden.ibm.com>
- Date: Mon, 14 Jan 2002 11:23:49 -0800
- To: werner.donne@re.be
- Cc: www-forms@w3.org
This is a good usage idiom. It is a good example of how different parts of the XML suite of specifications can be integrated to deliver end-user applications. It's also a good case in point for why specifications like XForms should not attempt to "standardize" such things at this early stage while we all gain experience from what is possible. What you describe could be implemented in a document profile that incorporates XForms and XSLT into an XHTML container --call it XHTML+XSLT+XForms. In summary, the fact that what you suggest is possible with no change to the base XForms specification is a good thing. >>>>> "Werner" == Werner Donné <werner.donne@re.be> writes: Werner> Hi, A simple but powerful extension would be to Werner> add the XSLT transform element to the head Werner> element set. The stylesheet in it would be Werner> executed on the instance data during the Werner> validate operation, right before the actual Werner> validation is done. Werner> A use case is for example to filter out "work Werner> elements" in a "work namespace" which are Werner> scattered through the instance data. A "work Werner> space" could also be created through the ref Werner> attribute of submitinfo. Anything next to the Werner> tree which will be submitted can be considered a Werner> work space. Werner> This doesn't work in all cases though. In a Werner> repeating structure, for example, it is not Werner> possible to maintain a work space node-set which Werner> maps one-to-one to the bound node-set of the Werner> repeat element. The work space elements could be Werner> inserted and deleted, together with the main Werner> elements, but not addressed. That is because the Werner> XPath expression to do that would have to use Werner> the root context instead of the normal Werner> evaluation context. In that expression the value Werner> of the position() function in the normal Werner> evaluation context is not available, unless Werner> there would have been (local) variables. That Werner> variable could be set starting from the normal Werner> evaluation context and evaluated starting from Werner> the root context. Werner> As a consequence, if one needs work elements in Werner> a repeating structure, they have to be Werner> maintained in the instance data, next to the Werner> actual elements the structure is supposed to Werner> manipulate. Werner> The transform element would make it easier to Werner> create self-contained forms for already existing Werner> XML messaging applications. Werner> Regards, Werner> Werner. -- Werner Donné -- Re BVBA Werner> Engelbeekstraat 8 Papenhof 15 B-3300 Tienen Werner> B-3583 Beringen tel: (+32) 486 425803 e-mail: Werner> werner.donne@re.be -- Best Regards, --raman ------------------------------------------------------------ T. V. Raman: PhD (Cornell University) IBM Research: Human Language Technologies Conversational And Multimodal WWW Standards Phone: 1 (408) 927 2608 Fax: 1 (408) 927 3012 Email: tvraman@us.ibm.com WWW: http://www.cs.cornell.edu/home/raman PGP: http://emacspeak.sf.net/raman.asc Snail: IBM Almaden Research Center, 650 Harry Road San Jose 95120
Received on Monday, 14 January 2002 14:24:36 UTC