[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XSLT compiler and syntax extensions
> A more developer-friendly XSLT 1.0 would be interesting and would not > need to be 100% 2.0 conformant; for instance, 2.0-grouping and getting > rid of the dreaded "result tree fragments" would be a nice step > forward. That step has already been done by David Carlisle for browsers at least by implementing the exslt:node-set() function for Internet Explorer: <!-- from http://dpcarlisle.blogspot.com/2007/05/exslt-node-set-function.html --> <msxsl:script language="JScript" implements-prefix="exslt"> this['node-set'] = function (x) { return x; } </msxsl:script> Most other browsers already support exslt:node-set(), like Chrome, Firefox, Opera and Safari. So using David's technique allows you to deal with the 5 major browser result tree fragments easily. I used that a lot for client side XSLT, see my "XSLT pointers" posting: http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/201009/ msg00179.html Demonstration of XSLT pointers: http://www.stamm-wilbrandt.de/en/xsl-list/xsltPointers/sevennodetypes.xml Btw, XSLT pointers might be useful as Michael posted this in another email: > ... for example, but it's less easy to see how > to implement a sequence containing both nodes and atomic values, or a > node-sequence that contains duplicate nodes. Perhaps you would have to > represent such sequences using the generate-id() value of the node, > dereferencing the IDs using keys. I did "XSLT pointers" because one of the seven node types, namespace nodes, cannot be matched with xsl:key -- XSLT pointers work around that limitation. Mit besten Gruessen / Best wishes, Hermann Stamm-Wilbrandt Developer, XML Compiler, L3 Fixpack team lead WebSphere DataPower SOA Appliances ---------------------------------------------------------------------- IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 From: Emmanuel Bigui <eb@xxxxxxxxxx> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Date: 11/18/2010 03:06 PM Subject: Re: XSLT compiler and syntax extensions Sent by: emmanuel.begue@xxxxxxxxx On Thu, Nov 18, 2010 at 12:15 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote: > Easy really. If the compiler needs to be able to compile itself then basically it amounts to rewriting Saxon in XSLT: very easy, probably, yes (I wonder why it has not yet been done...?) But what exactly is the need? Who is the target audience? A more developer-friendly XSLT 1.0 would be interesting and would not need to be 100% 2.0 conformant; for instance, 2.0-grouping and getting rid of the dreaded "result tree fragments" would be a nice step forward. But then of course it would amount to create yet another XSLT version (maybe close to 1.1 ...?) and would only add to the confusion. And who is the target audience? If we're only talking about browsers, then the target audience is XSLT developers that can't or won't write Javascript (since JS support in modern browsers is nothing short of excellent). Or, the target audience is people dealing with tasks that ** need to be done in a browser ** and for which: 1) XSLT would be the best tool 2) XSLT 1.0 is clumsy/impossible to use What are those tasks and who are those people (and how many of them are they ;-)? Besides browsers, what other environments have good XSLT 1.0 support and zero XSLT 2.0 support? Regards, EB
|
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
|