RE: integrating assign in the standard

Hi,

Thank you for your consideration and quick response.

We do not plan to undertake an uphill struggle with the WG, as we are only 
trying to contribute some information to help the WG make the best 
decisions for the language and its users.  We are also ready to contribute 
more if it can be of use.

The use cases and patterns affected by assign are important enough to have 
great portability and compliance issues for users and applications, unless 
assign, or some equivalent, is included in the standard.

If "The root cause for this is that the semantics of this extension have 
never been properly described", describing those semantics sounds like a 
good first step.
Gathering the use cases and patterns that require assign (or mutability) 
and analyzing the implied semantics may be useful, at least to layout the 
requirements.
A constructive and respectful forum environment may also be useful for this.

The saxon:assign extension currently provides the required features and 
functionality but if it goes, a replacement is needed.

Can Saxon keep its assign extension until a more permanent alternative is 
available ?

How can we efficiently help bring about this alternative ?

Thank you,

Andre Cusson
01 COMMUNICATIONS


At 03:43 2005-07-04, Michael Kay wrote:
>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/>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 "<https://sourceforge.net/forum/message.php?msg_id=3212142> 
>Eliminating saxon:assign" message track of the source-forge Saxon 
>OpenDiscussion forum at 
>https://sourceforge.net/forum/forum.php?thread_id=1305798&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