RE: Question: XSL & Dynamic Changes During Run-time

[Jonathan Marsh <jmarsh@xxxxxxxxxxxxx>]

		-----Original Message-----
		From:	L. John Junod [mailto:junod@xxxxxxxxxxx]
		Sent:	Tuesday, February 24, 1998 2:23 PM
		To:	'xsl-list@xxxxxxxxxxxxxxxx'
		Subject:	Question: XSL & Dynamic Changes During
Run-time

		Given:
		"7.2. Limited Side-Effects

		The ECMAScript language supports side-effects. However,
unrestricted use of side-effects in XSL would create serious implementation
problems for progressive rendering and for handling large documents. In XSL
it is an error for **code** in a **construction rule** to change a **global
variable**, or any object reachable from a global variable. It is also an
error for code to change any object reachable from an object specified as
the value of an inherited characteristic.

		Enforcing these restrictions would be difficult for XSL
implementations that use existing JavaScript implementations; therefore,
this is not required of XSL implementations. However, the results of
applying a stylesheet causing side-effects is unpredictable in systems that
do not enforce the restrictions."


		Assumed Definitions:

		1) Code == ECMAScript
Yes.  Or more broadly, the procedural escape that XSL provides.  The
proposal defines this as ECMAScript, but if we changed to a different
scripting language, the restriction would remain.

Also note that direct manipulation of either the input tree or the output
tree would also constitute side effects.  A rule must leave everything just
as it found it.

		2) Construction Rule: ==:"The construction rules contain a
pattern to identify specific
		 elements in the source tree, and an action to specify a
resulting sub-tree of flow objects. "

		"In addition to construction rules, XSL also supports style
rules....."

		(Thus, rule elements are **construction rule** elements?
Right?)
No.  Side effects can apply to any escape to code.  Right now this means an
<eval> element in the action of a construction rule, or an ?=function()?
attribute calculation in either a construction rule or a style rule.  Rule
elements generally means both construction rules and style rules.

		3) Global Variable == for XSL defined within the
define-script element (equiv to C global var.)
		<note regarding global variables in ECMAScript>
		NOTES:  If ECMAScript is JAVA then "Java in a Nutshell, 2nd
Edition, Oreilly, David Flanagan, 
		ISBN 1-56592-262-X"  says in regards to global variables:
Pg 16 "As a language that
		is designed to support dynamic loading of modules over the
entire Internet, Java  takes
		care to avoid name space conflicts.  Global Variables are
simply not part of the language.
		Neither are 'global'  functions or procedures for that
matter."
		Futher, pg 55 "What is different from a global variable in C
is that there is no possiblity of name conflicts....Since each class
variable must be part of a class and must be referred to with its class name
each has a unique name."
		</note>
ECMAScript = JavaScript, not Java.  JavaScript does have global variables
and functions.
Global variables in XSL mean variables defined in the <define-script>
element.

		MY READING

		Per
		"7.5. Scripting in XSL
		The scripting language can be used in XSL in a number of
different ways:
		At the top level (**outside of any construction rules**),
variable declarations and function definitions may be specified within a
define-script element.

		<define-script>
		  var defaultFontSize = "12pt";

		  function hierarchicalIndent(elementType, element)
		  {
		    return length(hierarchicalNumberRecursive(
		                  elementType, element)) * 12pt;
		  }
		</define-script>"


		Therefore,  "defaultFontSize" is a global variable and
"hierarchicalIndent(elementType, element)" is a global function.

		Q1: Is this correct?
Yes.   Global functions don?t introduce side-effects.  Global variables can.
In the above example, the ?defaultFontSize? should be treated as a global
constant instead of a global variable ? i.e. any script can read the
variable, but writing to the variable constitutes a side effect and can
cause unexpected behavior in the output.  For instance, if the
hierarchicalIndent function above modified the value of defaultFontSize,
this would be considered a side effect.  Since XSL does not specify the
order or frequency of rule execution, we can?t guarantee that a rule will be
called only once per element, in a certain order, or at all, so changes to
global variables do not result in predictable behavior.


		Q2: Is there a planned way to maintain a "session" while in
a web where a global record is kept of the session from within XSL given the
words regarding the ability of a rule to change (denied) a global variable
in 7.2?
I think you are asking if I can use globals to define an environment for XSL
processing.  Yes, I should be able to set up my state before processing,
including setting global variables (even if they involve some initial
calculation), global environment variables (if we come up with a way to pass
these in), and the input document tree.  Once these are
loaded/parsed/initialized, any further changes are considered side effects.
Beyond this set-up stage, the XSL processor maintains the state and the
control of processing internally.  No user-accessible session info is
available.

		Q3: Is there a way in XSL (or via the scripting extension)
for a user to input a value into a form, which then is recorded in a global
variable, and then change the behavior of the subsequent rendering?  That
is, can one set a filter based upon a run-time user input value (or choice
from a list of say checkboxes)?  As in Q2, does the restriction on setting
global variables from within rules in section 7.2 apply
Yes, we are looking at ways to provide parameters or environment variables
to the stylesheet.  My guess is that these would be held constant for the
duration of the stylesheet processing.  If any of these variables changed,
we would most likely have to reprocess the whole stylesheet from scratch.
But what we are really trying to allow is changes to the XML source
(triggered by a form in your example) could automatically be reflected in a
minimal reprocessing of the stylesheet and update of the display.  So in
effect, we can optimize for minimal updates as long as there are no global
side effects.


Jonathan Marsh
phone   425.703.4591
 <mailto:jmarsh@xxxxxxxxxxxxx> jmarsh@xxxxxxxxxxxxx

		


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