xml-dev - Re: Doing it the other way around (Re: transformations)

[Alexey Gokhberg <alexei@bluewin.ch>]

> 
> > Alexey Gokhberg wrote:
> > There is nothing unusual in combining several programming languages
> > together. The common example (already cited in this thread) is SQL.
> 
> > Richard Lanyon wrote:
> Oh, sure. I use Perl/MySQL myself all the time when writing webpages,
> but it isn't particularly neat, I just know it works.
> 

I guess, you are using this solution because it better fits your needs,
than any other solution. Ability to fit the users's need is the ultimate
criteria. Therefore, this fact just proves that the concept I advocate
is useful.

> > Alexey Gokhberg wrote:
> > The fact is, that there are (almost) no pure transformation tasks in the
> > real world. In most cases XML transformation proper is combined with
> > some other form of data processing.
> 
> > Richard Lanyon wrote:
> But saying "XSLT is fine because if there's a transformation it can't
> do then you just embed it in another language" does make it seem as
> though there were space for a better language, or for improvements to
> XSLT.
> 

Yes, there is always space for a better language, and certainly, XSLT
can be improved. Personally, I would be happy to see on this list the
practical discussion of prototypes for the better languages and for
proposed XSLT enhancements - their syntax, semantics and, ideally, the
reference implementations. Case studies that compare various existing
tools that might provide alternative to "100% pure XSLT" are also very
much appreciated.

> > Alexey Gokhberg wrote:
> > The natural solution is to select an appropriate
> > programming language to code each module, then to use some (e.g.,
> > scripting) platform to integrate modules.
> 
> > Richard Lanyon wrote:
> I entirely agree, but I didn't think that's what was meant in the
> original post by "embedding" XSLT in ECMAScript.
> 

Why??? By simple combining XSLT and ECMAScript, you can overcome a lot
of stupid problems which arise when you try to do everything in "100%
pure XSLT". And, what is also important, you can do this RIGHT NOW,
without waiting when W3C will issue the next XSLT recommendation.

And, strictly speaking, in my original posting I promoted an idea of
integration of XSLT, XPath, DOM, SAX, ... - all battle-proven and widely
accepted technologies - under aegis of ECMAScript, in order to combine
their advantages. Sounds a bit different than the simple (though very
useful) combination of ECMAScript and XSLT?

Finally, please note that we in Unicorn Enterprises very seldom offer
just pure ideas. Behind this particular solution there is a public
(critics is very much appreciated), full-scale reference implementation,
which will very soon reach the industrial quality.

Regards,

Alexey