RE: XSLT 2.0 - Proposal for additional Varaible requirement.

Changing XSLT from being a functional language without side-effects into a
procedural scripting language would certainly ease the learning curve for
people coming to it from things such as JavaScript. However, there are good
reasons for the fact that the language is designed on functional lines, and
I don't think anyone on the working group wants to change this principle,
which is pretty fundamental to the way the language is conceived.

I myself found it difficult to get over the learning curve initially, but
like most people who have made the effort, I found that in the longer term,
the benefits in terms of improved maintainability of code are quite
considerable. Please persevere!

Michael Kay



> 
> To date I have been fairly successful in achieving my XML 
> transformation goals with XSLT 1.0.  Early on I ran into the 
> same problem which everyone has/will: variable values can not 
> be changed once established.
> 
> However, I am finding it an increasingly aggrevating 
> limitation that there is no easy way of accumulating a final 
> result in a piece-meal or iterative fashion in a manner than 
> allows the final accumulation to be utilized within the 
> transformation process.
> 
> XSL(T) transforms input XML into something else.  This 
> transformation is state driven.  This state is established by 
> the input XML and by XSL stylesheets.  For simple 
> transformations, it is sufficient that this state is 
> established directly.  Complex transformations will 
> frequently require derived state information.  Derived state 
> information can not always be established 
> immediately/directly/recursively.
> 
> XPATH 2.0 is introducing several new requirements which 
> indirectly (and
> partially) address this very issue:
>   a) 1.3 Must Support Explicit "For Any" or "For All" 
> Comparison and Equality Semantics
>   b) 1.4 Must Extend Set of Aggregation Functions (e.g. max(), min()).
> 
> These requirements are providing solutions to problems which, 
> while conceptually simple, tend to be very difficult to 
> articulate in XSLT 1.0 in a usable manner.  These, in my 
> mind, are a direct response to instances of the more general 
> issue of not being able to accumulate a result.
> 
> The requirements above are probably very important.  However, in my
> mind:
> a) they will only lend themselves effectively to homogeneous 
> elements/node-sets,
> b) they are point-source solutions to a more systemic issue.
> 
> >From seeing the issues raised in some of the news groups, I 
> know this a
> fairly common/general issue with XSLT.  From a statement made 
> under XSL 2.0 Requirements Goals ("Turning XSLT into a 
> general-purpose programming language."); I suspect that this 
> issue is being tabled under the category of "not a 
> general-purpose programming language".
> 
> Observation 1: Requirements should never be stated in terms 
> of negatives.  It is usually a bad idea to try to describe 
> something in terms of what it is not.
> 
> Observation 2: XSLT _is_ a programming language.  In several 
> references I have read it is explicitly described as a 
> "declartive programming language".
> 
> Observation 3: This issue is pervasive.  As such it would 
> seem that XSL 2.0 should attempt to address it.
> 
> Regards,
> Ed Knoll
> 
> --
> Edward L. Knoll   Phone (work)     : (719)484-2717
>                   e-mail (work)    : f49660c@cosd.fedex.com
>                   e-mail (business): eknoll@sf-inc.com
>                   e-mail (personal): edward@elknoll.com
>

Received on Saturday, 3 August 2002 17:19:23 UTC