Add XSLT transform element to head element set

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