OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

Well, Javascript works pretty well on millions and millions of browsers.
Runs on a most web servers, too.  Folks have been integrating it into Apache
SOAP with some success.  Probably not a screamer, performance-wise.  But
probably not the bottleneck, either.  Your mileage may vary.  If you don't
like it, don't use it.  It is optional, after all.  

The RDDL processing you suggest should probably be resolved externally (e.g.
server side, before sending to a browser).  Presumably, you've received the
stylesheet appropriate to the current output device, thus the appropriate
extension should have been identified and included.

take it easy,
Charles Reitzel

On Thu, 01 Mar 2001 23:06:45 +0100,
Robin Berjon <robin@knowscape.com> wrote:
>At 13:31 01/03/2001 -0800, Steve Muench wrote:
>>I (personally, not speaking for the WG here) don't happen to
>>be a believer in some kind of look-it-up-and-magically-download-
>>scheme to download and run the "right" implementation of some function.
>Nevertheless, xsl:script allows for precisely that through it's src
>attribute. Given that, don't you think that relying on extension namespaces
>pointing to an RDDL document containing 1) information on how a human being
>can get the extension should he want to do it by hand and 2) a pointer to
>implementations of the extension (possibly in several languages so that the
>processors can choose the one they know about, or their favoured one)
>should the processor be allowed to fetch extensions automatically (possibly
>only within a trusted network) is far superior to what xsl:script offers ?