RE: integrating assign in the standard

I've been following the discussion on the Saxon forum with interest even
though I haven't contributed much to it. I agree that there are some
algorithms that are very difficult to express without this kind of
capability, or that execute very inefficiently (under typical
implementations...) if written in a purely functional style. However, the
existence of a need isn't in itself sufficient to justify changing the
language. Some users also have an acknowledged need to access information
outside the scope of the data model; sometimes we have to decide that for
certain tasks, they should be using a different language.
 
I'll start by saying that you'll have an uphill struggle convincing the WG
to address this requirement (and it certainly won't happen in XSLT 2.0). As
well as providing convincing use cases, you need to outline what the
semantics of "assign" would be, or rather, how the current language
semantics would be modified to address it. The thread on the Saxon forum
started because of a remark I made that saxon:assign was becoming difficult
to maintain because it didn't survive various optimisations, and this is
becoming an increasing problem as Saxon moves gradually towards global
optimization of the whole stylesheet. The root cause for this is that the
semantics of this extension have never been properly described - instead
it's specified intuitively by appeal to procedural languages with a quite
different semantic model.
 
In the WG we spent time again recently on trying to relax the restrictions
in xsl:result-document, and failed to come up with a semantic model that
allowed us to specify the behavior if these restrictions were removed. If
it's difficult to do with xsl:result-document, then it's certainly even more
difficult with "assign".
 
The same problem exists, of course, with extension functions that have
side-effects. In this case the specification can wash its hands of the
problem by pointing out that the semantics of extension function calls are
implementation-defined.
 
Michael Kay
http://www.saxonica.com/


  _____  

From: public-qt-comments-request@w3.org
[mailto:public-qt-comments-request@w3.org] On Behalf Of Andre Cusson
Sent: 04 July 2005 00:33
To: public-qt-comments@w3.org
Subject: integrating assign in the standard


Hi,

There has been recent issues and discussions about the support of "assign"
and associated functionality, ex: 
- the "Template recursion, StackOverflowError, saxon:while and variable
assignability" message track on saxon-help@lists.sourceforge.net, continued
on 
- the " Eliminating
<https://sourceforge.net/forum/message.php?msg_id=3212142> saxon:assign"
message track of the source-forge Saxon OpenDiscussion forum at
https://sourceforge.net/forum/forum.php?thread_id=1305798
<https://sourceforge.net/forum/forum.php?thread_id=1305798&forum_id=94026>
&forum_id=94026 ).

Assign is currently an extension supported by some implementations (ex:
Saxon).  

Recently some have been proposing to drop assign from XSLT as there should
be other (more standard) ways to achieve equivalent results.  

We have been looking at this for little while and would like to propose not
only that assign could be supported as an extension but that assign should
be an integral part of the XSLT standard for the simple reason that
important and fundamental processing patterns can not be efficiently
expressed in XSLT, without assign.  These assign dependent processing
patterns map-out to many essential and often non-trivial use-cases, and
include: 

- support of (user) global variables in scripting languages written in XSLT
(like the XML-based layout scripting language of our publishing engine)

- efficient run-time traversal and processing of large networks while
avoiding loops (like traveling salesman trying to mark paths that he has
already visited, as he traverses the graph) 

- efficiently record and monitor global processes (like avoiding the XSLT2.0
"Cannot write more than one result document to the same URI" error (and
avoiding duplicates/overwrites) when re-generating (ie. updating), from its
XML sources, a web site, whose pages are already referred to by other sites
and bookmarks, and where, while traversing the tree of source XML documents,
at every page node, before generating the page, the transform needs to check
if that URL has already been used, add it to the list of done pages if it
has not or report (ex: trace) the duplication.


For real-world examples, we have an XSLT application currently on-line, with
about 25K lines of XSLT 2.0 and about 400 global variables of which 17 are
assignable variables that specifically fit patterns for which no other
equivalent algorithm could be found to replace the ones using assign,
confirming (still, so far), the requirements for Assign.

In fact, assign is so important, that it has to be part of the standard
(like regex, number formatting, escaping, html serialization, keys, etc.) to
allow non-trivial applications to be conformant and portable.

In no way are we advocating that assign should be used in cases other than
those for which there is no reasonable alternative.

Of course, the name "assign" is not really important, but it is the
occasional mutability offered by the associated functionality that is key
and unique.

Do not hesitate to contact us for more information.

Thank you for your consideration.

Andre Cusson
T: (1) 514 583 0601
01 COMMUNICATIONS