On Fri, 07 Sep 2007 03:41:22 -0600, Colin Paul Adams
<colin(_at_)colina(_dot_)demon(_dot_)co(_dot_)uk> 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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--