[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: Microsoft extensions to XSL (was RE: how to call Javascript function in .xsl file) function in .xsl file)

---

---

Didier PH Martin wrote:

> Hi,
>
> If the goal is to have any kind of script language supported, then there is
> a high probability that Microsoft will allow (if that is not already the
> case) to interchange script languages. In fact, Perl, Python, JavaScript,
> VBScript all can work within a web page , in Windows Scripting Host or in
> ASP pages. This is because, within the Microsoft's component architecture
> all these script engines support the same interfaces. Remember that DCOM is
> not Microsoft specific, their implementation on windows is. For example
> Software AG owns the implementation on several Unix, the Linux group own
> (sort of) the implementation on Linux. So, because Microsoft took from the
> beginning an open architecture for script languages, I don't see why we
> should associate Microsoft with a strict JavaScript aka ECMAScript
> implementation.

Yah, but DCOM is an abomination.  CORBA for all its flaws is a far superior
solution to DCOM.  Why anyone would want to use DCOM other than to promote MS
tools, is foreign to my understanding.

> In fact did anybody tried to call an other script engine from Microsoft XSL?
> like for instance VBScript or PerlScript? Maybe it is already in place?
> maybe their name space can resolve script engine switching.
>
> Let's experiment with it. And if that is the case, it remains now to work on
> the tag stuff. i.e. script invocation.
>
> In HTML you can invoke (not on all browsers :-( a script engine with a
> property specifying the language. So, the specs should then specify what
> property type and value to set. Obviously, Microsoft has all the interest in
> the world to support also VBScript doesn't it? And again, because of the
> script engine architecture, it will also support PerlScript, PythonScript
> and the other engines supporting the same interfaces.
>
> Thus, the problem is not so much Microsoft than the lack of specs on this
> side ;-)
>
> And I agree with an other participant that when you try to do practical
> things, XSL is insufficient. Script support and a DOM is essential to
> compensate for what is missing in XSL (Don't try to redo an other PL1 after
> all that time we should have enough experience not to redo the same mistakes
> doesn't it? ). And if we can use either PerlScript, PythonScript, VBScript
> or JavaScript to start with, we are then in a better position to real stuff.

I seriously disagree here.  XSL is not a programming language.  If it evolves
into something of a real programming or scripting language then everyone might
as well just use Javascript, Java with servlets, or any other scripting solution
to do everything.  I think there is an unfortunate perception out there that XSL
is supposed to do every type of content processing imaginable both on the client
and server side.  If XSL turns into a bloated spec, there is no reason to use it
as there are already products like Cold Fusion which do all of what XSL does and
more.  XSL I feel should be simple and geared somewhat towards the end-user.
Some companies I am sure would like to embrace and extend XSL for their own
selfish purposes, so I pray that this never happens.  Thank god that XML has not
been mutated very much by software vendor politics to date.

> My machine already has PythonScript, PerlScript, JavaScript and VBScript.
> I'll try to see if with IE 5.0 I can invoke a script engine other than the
> javaScript engine. remember Bacon, nothing like experiment. A lot better, in
> fact, than playing bad guys good guys ;-)
>
> Question for who knows. Why Netscape after some years on the market do not
> support more than one script language? any reason? Just curious to know.

Probably because despite the fact Netscape Communicator is quite guilty of code
bloat, I think the engineers at Netscape at least have some concern for not
turning Netscape Communicator into another MS Office monstrosity.  I cannot
think of one Microsoft product that is what I would call compact and concise
from an engineering standpoint.  All in all, I think Netscape is wise not to
support every programming idea known to man.  In particular, the idea not to
directly support Java in the future may be a good thing with the advent of the
Java plug-in and the so called Open-Java API.  Working to make your product
interoperable with other vendors benefits everyone but the software monopolies.
Microsoft on the other hand has been guilty in the past of "embracing and
extending" other technologies and I am afraid that may be the motive with XSL.
It would be nice if there was a public statement by Microsoft that they will not
work to own the XSL spec as so many people seem to fear.

As far as XSL technically is concerned, a client I have is very happy with the
current XSL draft as is and they have been able to do lots of neat things with
it on the server side.  Check out http://www.javalobby.org as it dynamically
generates pretty much all of the content dynamically using servlets, XML, and
XSL.  It is very fast on the server side and most people that have seen it are
very impressed that it uses such bleeding edge technologies as XML, DOM, and
XSL.  Currently the technologies the product they have that runs the site uses
XML 1.0, the current DOM implementation, SAX, and of course XSL as well as some
Java specific stuff like JDBC and Servlets.

Note: on the client side unfortunately the home page has way too many tables and
too much JavaScript so rendering the tables in the browser can sometimes take a
second so don't be concerned with the server-side performance.

All engineers are guilty from time to time of trying to solve programming
roadblocks with hacked up patches instead of spending a little bit of time
sitting back in a chair and trying to think of an elegant solution.

My 2 cents,

Tyler


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---