[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: Ed Nixon <ed.nixon@xxxxxxxxxxxxxxxxx>
Date: Tue, 10 Nov 1998 15:20:54 -0500
call javascript functions in vba
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


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.