[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

Subject: RE: Microsoft extensions to XSL (was RE: how to call Javascript function in .xsl file) function in .xsl file)
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Tue, 10 Nov 1998 18:11:15 -0500
call javascript from vbscript
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.

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.

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.

Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Ed Nixon
> Sent: Tuesday, November 10, 1998 3:21 PM
> To: 'xsl-list@xxxxxxxxxxxxxxxx'
> Subject: RE: Microsoft extensions to XSL (was RE: how to call Javascript
> function in .xsl file) function in .xsl file)
>
>
> I thought the idea was to create a XSL mechanism for recognizing
> scripts that
> was language independent, i.e., did not pre-determine the use of
> Java or any
> other particular language. For example, there are 'many
> thousands' of Perl
> programmers out there just as there are (and we must forgive them
> their sins)
> VisualBasic or VBA or VBScript (or whatever it's called this month)
> programmers. This seems like a doable, laudable and suitable task for the
> standard and probably worth waiting for. We sometimes forget that
> a lot of good
> stuff can be done with 'old-tech' methods. I say this having
> spent the morning
> waiting for ASP pages to (fail to) process themselves (before
> timing out) off
> the MS XML/XSL site.
>
> I agree with another poster, however, that a little more PR-like
> communication
> from the working group might help to dampen and dissipate some of
> the clouds of
> smoke that are starting to blow into the list.
>
> 	...edN
>
> -----Original Message-----
> From:	Didier PH Martin [SMTP:martind@xxxxxxxxxxxxx]
> Sent:	Tuesday, November 10, 1998 2:17 PM
> To:	xsl-list@xxxxxxxxxxxxxxxx
> Subject:	RE: Microsoft extensions to  XSL (was RE: how to
> call Javascript
> function in .xsl file) function in .xsl file)
>
>
> if the group decided that ECMAScript - an accepted standard and
> part of the
> two main browsers (and thousands of people knowing this language)
> - is not a
> way to provide that capability. What is the way? Do the group has
> any other
> suggestion? Will all these thousands of people have to learn again another
> language? Does it make sense? where can we read the reasoning behind this
> kind of statement? Is it opened?
>
> At least IETF workgroups allows external parties to express their
> points and
> keeps a log of all conversations. So, Where can find the reasoning behind:
> "it is not appropriate", what are the premises, the reasoning behind this
> conclusion.
>
> So instead of following the actual "let's beat Microsoft" lemming
> behavior,
> what's behind this statement?
>
> Didier PH Martin
> mailto:martind@xxxxxxxxxxxxx
> http://www.netfolder.com
>
> > -----Original Message-----
> > From: owner-xsl-list@xxxxxxxxxxxxxxxx
> > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Chris Maden
> > Sent: Tuesday, November 10, 1998 12:18 PM
> > To: xsl-list@xxxxxxxxxxxxxxxx
> > Subject: Re: Microsoft extensions to XSL (was RE: how to call Javascript
> > function in .xsl file) function in .xsl file)
> >
> >
> > [Denis Hennessy]
> > > For my work, the dropping of script support in the current draft has
> > > been a major pain.
> >
> > For your work, you probably shouldn't be using a draft-in-progress.
> > The Working Group decided that ECMAScript was not the way to provide
> > that capability, and that it was better not to put something
> > misleading in the draft, and to figure out the right way to do it
> > before publishing anything on that front.
> >
> > > If Microsoft's processor is the only one that supports scripting,
> > > then the platform decision is clear. I don't care whether the tag is
> > > called <ms:eval> or <xsl:eval>;
> >
> > If they are using the namespace declaration
> >
> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
> >
> > which their examples do, then all <xsl:*> elements are from a
> > namespace controlled by the W3C.  There is no <eval> element in that
> > namespace, and their documentation of such, explicitly from that
> > namespace, is questionable at best and criminally fraudulent at worst.
> >
> > > the functionality is needed for a great many applications and if the
> > > standard doesn't provide it, then proprietary extensions must.
> >
> > The standard doesn't provide it because there is no standard.  There
> > is a draft, explicitly in progress and not done yet.  This
> > functionality is intended, but not this way; investing effort in
> > ECMAScript-based solutions will only waste your time.  So I disagree
> > that proprietary extensions are necessary, but even if they were, this
> > isn't a proprietary extension; it is a lie about the contents of the
> > http://www.w3.org/TR/WD-xsl namespace.
> >
> > -Chris
> >  absolutely not speaking in any way for the XSL WG
> > --
> > <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
> > <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
> > "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
> > <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>
> >
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.