W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2002

XSLT 2.0 - Proposal for additional Varaible requirement.

From: Edward L. Knoll <ed.knoll@cosd.fedex.com>
Date: Thu, 1 Aug 2002 17:36:08 -0400 (EDT)
Message-ID: <3D49A8B2.33C4EE41@cosd.fedex.com>
To: public-qt-comments@w3.org

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
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
a) they will only lend themselves effectively to homogeneous
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

Observation 3: This issue is pervasive.  As such it would seem that XSL
2.0 should attempt to address it.

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 Friday, 2 August 2002 11:20:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:56:43 UTC