Subject: Re: [xsl] [xslt 2.0] Local functions From: Justin Johansson <procode@xxxxxxxxxx> Date: Thu, 19 Jul 2007 12:11:35 +0900 |
Abel, thanks for your constructive criticism, particularly that on language aids; it's great to have a good devil's advocate on your tail :-) >or one can do: ><xsl:value-of separator="" select=" > for $a in 65 to 90 return > for $b in $a to 90 return > codepoint-to-string($a), codepoint-to-string($b)" /> Clearly less a higher signal-to-noise ratio if you do it this way rather than lots of xsl elements. Of course in the more general case in which you want to create mix literal elements into the result sequence, I can understand that you would probably opt for the noisier method. Isn't the problem all about how to escape between literal result elements and XPath statements? Doesn't XQuery address that with use of curly brackets .. at least from lit elements into XPath though not back again? >> To that end, I'm working on a translator from a language with a higher level >> syntax (ie. either reduced XML or no XML at all) into XSLT 2.0. >> The translator itself is an XSLT stylesheet, though eventually the translator >> itself will be written in the language of the higher level syntax. >> > >Interesting as a theoretical exercise. Why would you reinvent a >language? Do you want people to learn a new syntax again, with all its >own peculiarities? It is far from a trivial task and it is highly >debatable whether it will bring more clarity or - even - higher >productivity. Note that there will be no handy language aids like with >Altova, Stylus Studio, Eclipse or Oxygen (which did I forget?), no >intellisense and auto-syntax completion etc. Do you really think you >will benefit from a new language doing the same job? Well to quote one Dimitre Novatchev: --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Reckon I've got both of these ingredients to invent here; imagination and XSLT :-) >If you do decide o reinvent the language, you can of course add the possibility for >local functions and translate them into their own namespace when you >transform them into XSLT. That's exactly what I've done already. >You might be interested in some projects of Dimitre who used XSLT to do >language parsing (JSON and XPath I believe). It may help you build your >own parser in XSLT for your lang-x to xslt translation. Yes, I believe Dimitre is working in this area (parsing with XSLT) as well. Actually I already have developed a general purpose lexical analyser generator that generates the appropriate XSLT for parsing symbols in language X. This is fully working now and achieves lexical scanning of XPath expressions with a great deal of transparency. Coupled with a YACC-like tool, I have the means to generate a fully fledged LALR parser in XSLT. So now it doesn't matter what the syntax of my ultimate higher level XSLT looks like; it's now just a matter of making the difficult choices in specifying what this language should look like and figuring out what escaping mechanism to use to switch syntax modes (if any). Current candidates include: 1. Stick with XML syntax but increase the signal-to-noise ratio based upon such metrics as frequency of use of attribute nodes in the XML-based source code as opposed to text nodes. 2. Adopt Haskell-ike notation. 3. Suggestions welcome. Do you have any idea why DSSSL, based on Scheme, was so unpopular? Justin Johansson Freelance XML / XSLT / XQuery Developer Australia procode(at)tpg(dot)com(dot)au
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [xslt 2.0] Local function, Abel Braaksma | Thread | RE: [xsl] [xslt 2.0] Local function, Michael Kay |
Re: [xsl] [xslt 2.0] Difference bet, Abel Braaksma | Date | Re: [xsl] [xslt 2.0] Local function, Justin Johansson |
Month |