- From: Edward L. Knoll <ed.knoll@cosd.fedex.com>
- Date: Thu, 1 Aug 2002 17:36:08 -0400 (EDT)
- 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 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 Friday, 2 August 2002 11:20:42 UTC