[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
Hi, 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
|
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
|