Re: XT extension mechanism

[info@xxxxxxxxxx (Flow Simulation)]

James Clark wrote:

> Just as with the HTML 4.0 OBJECT tag, there is no restriction to Java
> and COM.  The attributes can point to a resource containing script.

Okay.   Interestingly I just noticed that for security reasons
ActiveX components cannot be instantiated from XSL in IE5.


> > That looks great.   But I'm not sure how this [<filter>] improves on the <eval> element
> > in e.g. the Microsoft XML Tutorial 15.   In the latter case you can drop scripted
> > elements into the template whereas with <filter> you need to programmatically
> > do this, I think.

> Huh?  In one case the script is in an attribute value, in another it's
> in content.

Sorry, badly phrased question.   I just meant that, for a very simple case,
it strikes me as simpler to evaluate in-line within the template.     Example:

<xsl:template match="amount"> 
  <H2>Chapter <xsl:eval>formatNumber(childNumber(this) + 5)</xsl:eval></H2>
  <xsl:apply-templates/>
  <H2>....here ends Chapter <xsl:eval>formatNumber(childNumber(this) + 5)</xsl:eval></H2>
</xsl:template>

To do the same with <filter> you have to do some programming to get a handle
to the result text and manipulate it.    That might seem simple enough to SAX users,
or programmers in general, but one would hope that XSL would be usable by people who are
only familiar with writing HTML and a bit of JavaScript.


> The major difference is that xsl:filter acts on the result tree, not the
> source tree.  A mechanism that acts purely on the source tree can never
> be adequate.  Consider the case where you want to use a different style
> for every other row of the table.  You can do this with eval as in the
> old submission, the differences in the row-handling are non-structural
> (eg a different value for an attribute).  But consider a variation on
> this case: the rows are generated from source data which is sorted using
> xsl:sort.  With xsl:eval you're out of luck, but with xsl:filter you can
> do it.

Yes, that is an advantage. 

But is a mechanism which acts purely on the _result_ tree adequate?
Are you thinking of supporting an <xsl:filter> _and_ an <xsl:eval>?
Can you use the DOM to read the source tree as well as the result tree fragment?


> Another major difference is that with xsl:eval (at least as it was in
> the submission) you can only generate strings.  With xsl:filter you can
> use the DOM to modify the element structure of the result: for example,
> you could transpose rows and columns.

Yes, it would be a bit risky to attempt to reorder the result tree within <xsl:eval>,
while the tree was still being constructed!    Being able to use the DOM
is very powerful.


> The key difference is state.  With an object-style filter there is no
> shared state between separate filter objects.  With a script-style
> filter there is a shared context that is used for the evaluation of all
> script fragments.  An object-style filter is something that I could
> imagine implementing in an interactive non-batch environment such as a
> WYSIWYG editor, because the effect of the filter is localized to the
> subtree of the result that the xsl:filter element contains.  With a
> script-style filter, the script code has global side-effects, and I
> think it would be very difficult to make this work in a non-batch
> environment.

I can see how this would hamper the building of a WYSIWYG environment,
as well as introducing dependency problems.
In applications like spreadsheets and word processors
the usual solution is to have the user choose whether to
render the whole document automatically after every relevant change, or only on request.
Perhaps one should avoid the use of globals, or at least emphasise that the order of
processing is not defined.

But what if you need some value computed from elements of another subtree, say.
Would you be forced to put the <xsl:filter> around templates which
matched near the root of the source tree, and use the DOM within
the filter object to "fix up" the result tree starting near the root?   I think this
would result in the same problems as having global state.


I think I could live without <xsl:eval> if I could access the source tree through DOM.
I would like the ability to use script though, with globals discouraged rather than forbidden. 
It would make using XSL more like using HTML, especially with the DOM support.   
Perhaps you could go a step closer still by

<xsl:filter type="text/javascript" onProcess="diddle(this)">

or even

<xsl:template match="price" onProcess="diddle(this)">

so that the script gets triggered by the "event" of having processed
the template rule.

Bill Ayers (BillA@xxxxxxxxxx)


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list