Re: [xslt 2.0] Local functions

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