[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSLT result tree fragment, with XSLT 3.0 and xsl:
Dave, are you thinking of sosofos? Specification of a sequence of flow objects? At 2023-04-11 19:12 +0000, Dave Pawson dave.pawson@xxxxxxxxx wrote: beneficial).Mike, don't forget the history of XSL? DSSSL provided a functional approach (totally convinced me it was instruction.XSL *included* xsl-fo originally (DSSSL history) - how did this impact the design? I can't remember the name (Ken H, can you help?) but DSSSL had a name for RTF's (rather strange IIRC) node-set.> > In the final (Nov 1999) 1.0 specification, result tree fragments are defined in more detail, and an equivalence to node-sets is recognized: > > A result tree fragment is treated equivalently to a node-set that contains just a single root node. However, the operations permitted on a result tree fragment are a subset of those permitted on a node-set. An operation is permitted on a result tree fragment only if that operation would be permitted on a string (the operation on the string may involve first converting the string to a number or boolean). In particular, it is not permitted to use the /, //, and []operators on result tree fragments. When a permitted operation is performed on a result tree fragment, it is performed exactly as it would be on the equivalent SAXON.> > Why the WG felt it necessary to impose these restrictions has always eluded me. In a post on this list on 15 Sept 1999 Tangi Vass wrote that the main weaknesses of the specification were (a) the non-mutability of variables, and (b) the inability to process result tree fragments as node sets. I responded by saying > > (a) But I personally believe the benefits of [immutability] do not justify the > restrictions it imposes, which is why I have implemented assignment (and > loops) in SAXON. [a decision I have come to regret], and > > > (b) I think that a function to convert a result tree fragment into a node-set > that can be further processed is a perfectly reasonable extension to the > standard and I've started experimenting to see if it can be done in by> > > the following day Dave Pawson asked > > If reuse of result trees was possible, 90% off my problems and ugly > hacks would disappear. I would really appreciate to know the rationale > why the spec says what is says (implementation problems?) > > > to which Oren Ben-Kiki responded: > > This was discussed in this mailing list; the main reason given was that -> limiting XSLT to a "single pass" it would be easier to implement > "incremental" XSLT processors. Such processors are deemed important for > editors etc. I don't know whether this was in fact the main reason for it of> and we wouldn't know unless some WG member confirms it. > > I personally don't buy this reason because (i) even a single pass > incremental XSLT processor is very hard to do and (ii) even with the current > restricted spec it is possible to write a multi-pass stylesheet. In fact > XSLT has hit the Turing-complete limit and attempts to justify all sort > restrictions in order to allow "automatic reasoning" of various types onit a> are pretty much futile. This is not to say that incremental processors or > other form of automatic reasoning on XSLT stylesheets would not be available > in practice; it is just that such tools would by necessity be limited to > "simple enough" stylesheets. > > [The idea of "incremental" XSLT processors was, I think, that if you made re-evaluating> small change to the source document, the XSLT processor would be able to > make corresponding adjustments to the result document without restriction> the whole stylesheet. Of course, that never happened.] > > As soon as XSLT 1.0 came out, it became rapidly clear that the > on result tree fragments was a great nuisance; and while thexx:node-set() > extension function provided a workaround, a new version of the specshould > combine node-sets and result tree fragments into a single data type.Making > this work in a backwards compatible way was not easy; a lot of the key ideas > came from Jeni Tennison. But a key part of the solution was a paradigm shift: whereas > in 1.0 instructions were described as being "instantiated", which caused things > to be "created" or "output", in 2.0, instructions were evaluated to return a result, > thus behaving in a much more "functional" way. > > Associated with this, XSLT 1.0 described a sequence of instructions as a > "template", but no-one ever used this terminology, because the term was > too closely associated with template rules and named template. The new > name "sequence constructor" was my invention. > > Michael Kay > Saxonica > > > > On 11 Apr 2023, at 16:05, Mukul Gandhi mukulg@xxxxxxxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > Hi Wendell, > > > > On Tue, Apr 11, 2023 at 7:09b/PM Piez, Wendell A. (Fed) wendell.piez@xxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > The essential difference is that you were not allowed in *unextended* XSLT 1.0 to treat the fragment like a tree. In 2.0 you were invited to do so. > > > > I think, its certainly more useful as an XSLT language, to treat the fragment like a tree by default (as you rightly wrote). This helps us solve, more kinds of XML transformation use cases, with the standard XSLT language (2.0 and 3.0). > > > > > > -- > > Regards, > > Mukul Gandhi > > XSL-List info and archive > > EasyUnsubscribe (by email) > > -- Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/s/ | Check our site for free XML, XSLT, XSL-FO and UBL developer resources | Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) | Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|