Conditional actions in XSL?

[Tony Stewart]

Henry Thompson writes:

		Richard Light <richard at light.demon.co.uk> writes:

		> The conditions for XSL are set by the structure that
you specify, e.g.:
		> 
		>     <element type="object">
		>         <target-element>
		>               <attribute name="REND" has-value="yes"/>
		>         </target-element>
		>     </element>
		> 
		> . . .
		>
		> I'm not sure about the ability to invoke a bit of
script when testing
		> the attribute value.  The XSL spec allows you to
invoke ECMAscript when
		> _setting_ attribute values on (output) flow objects -
there is no reason
		> at all why it couldn't allow the same feature when
_testing_ attribute
		> values on source elements.  (Obviously in this case
the script would
		> have to return true/false rather than a string.)

		You're right, in XSL as currently proposed you can't do
that, but it
		is consistent with the existing (but unimplemented) part
of the DSSSL
		model of construction rules via the 'query' construction
rule, so not
		out of the question in principle.

The more XSL allows us to call scripts at _any_ stage of the process,
the better. Most of the action of delivering XML documents over the web
will take place when you apply the style rules to the text. Many of the
things our clients are asking us to do with style rules, such as
applying formatting or triggering browser behavior based on combinations
of document context and conditions outside of the document (who is the
user? which option did she select two pages back? is the pump running
hot right now?) require pretty serious use of scripts to fire external
queries and set/get memory variables.* To the extent that XSL contains
non-critical restrictions on when we can make those calls and what we
can do with them, I'd like to see those restrictions removed.

*(Though an alternative to maintaining traditional memory variables
could be to manipulate attributes of the parsed tree, provided that the
scripts were allowed to get at it... style rules manipulating the DOM...
there's food for thought.)

Btw, any chance of removing the requirement that we must use ECMAScript
as the first layer we shell out to? I'm not clear what the standard
gains by this. I'd rather see a mechanism by which we declare what
language we're shelling out to, like declaring an encoding, or perhaps
some form of standardized API. (I'm new to this thicket of
standardization issues so don't want to push specific suggestions too
hard; just looking for less restrictive options than always using
ECMAScript.)

Regards,

Tony Stewart
RivCom
"Publishing Structured Information"
tony.stewart at rivcom.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)