[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Microsoft extensions to XSL (was RE: how to call Javasc
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
|
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
|