[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] XSLT 2.0 in the Browser (was: Re: [xsl] In Search of People Who Know About and/or Use the Document Function)


Subject: [xsl] XSLT 2.0 in the Browser (was: Re: [xsl] In Search of People Who Know About and/or Use the Document Function)
From: "M. David Peterson" <m.david@xxxxxxxxxxxxx>
Date: Fri, 07 Sep 2007 08:35:07 -0600

On Fri, 07 Sep 2007 03:41:22 -0600, Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx> wrote:

so what about Saxon.NET then?

In all honesty I have absolutely no clue if IKVM.NET would be enabled to run via Silverlight. Of course I can't think of any reason why you couldn't just write a Java plug-in wrapper around Saxon Java, and in doing so save the 4 megs of compressed overhead that comes along for the IKVM.NET ride. Of course you wouldn't have direct integration with Silverlight, but Silverlight provides direct access to the DOM so, again, I can't think of any reason why this wouldn't and shouldn't just work.


Probably a conversation for the Saxon-Help list. I'll move this particular conversation over there, though outside the context of Saxon it would seem appropriate to continue the updated subject matter here on XSL-List. In this regard,

* What are the challenges and limitations of getting an existing XSLT 2.0 engine to interop and be made accessible via the DOM?

* Is it possible to invoke a non-native XSLT process via a PI? If yes, which browsers provide these types of low-level hooks?

* What are the drawbacks (e.g. if someone installed a plug-in would the existing 1.0 processor still be accessible via PI-based transforms, or, in other words, would it be possible to sniff for a particular PI and, if it doesn't exist, pass it to the native XSLT processor?)

I'm sure there are other questions/technical limitations. Anybody care to jump in and take this conversation by the reigns?

--
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155



Current Thread
Keywords