Subject: RE: Future XSLT expansion From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Tue, 21 Mar 2000 07:30:40 -0500 |
Hi Tom, Tom said: Personally I have a public static NodeIterator stringToNodeList(String xmlStr) method, e.g. select="vdoc:string-to-node-list($blip)" for use in stylesheets, and it would be just great to have it in the core, without worrying about API at all. Didier replies: Or a less language dependant way would be to have ECMA script as the recommended script language, i.e. that ECMA script be part of XSLT. so that we could have: <xsl:script> function(string) { .....the function can return a node-list or one of the XSLT data types ..... } </xsl:script> This way, an extension would work in any environment. The problem with a Java centric solution is that it is not a) standard b) practical for implementations realized with other languages like, for instance, C++. But, I would like also to be able to create such functions is a compliant way so that my xslt style sheet can run on different user agents or server side processors. [Tom' code example...] Tom your code sample shows that extensions are useful to compensate for the actual XSLT blind spots. Now, if I simply could have your code to run on an other C++ based engine, this would be even better. This does not mean that Java is not a good language but simply that it is not the only language used to implement XSLT engines. But I should admit that I too have to create XSLT extensions to provide me the needed functionality. The adverse problem I am creating each time I am doing this is that the style sheet is not portable and can only run on my own XSLT engine version. If I where to put a priority on the agenda of the XSLT WG this would be the question of scripting (what is the standard script language that can be made part of the recommendations - What are the basic functions/objects added to the core scripting language that make sense in the context of XSLT). Maybe the XSLT WG needs the equivalent of the DOM WG (for the objects/functions added to the "official" script language - this, in addition to the actual DOM objects). This whole discussion just emphasize the fact that a script language is badly needed to fulfill our so diverse processing needs. This also shows that a markup based styling/transformation language has maybe some limitations. Or simply, that scripting can provide a way to have disciplined extensions and that some of these extension may find their way as new xsl instruction. However, in this last case, as Paul, already mentioned, we may end up with a bloated XSLT language. So, maybe having a standard script language may resolve the bloatware problem and will still allows to get the needed functionality. In this kind of world we would simply exchange libraries (i.e. collection of scripts). Funny, we already learned that in the DSSSL world but the knowledge wasn't completely transferred or simply that the W3C group ran out of time... Cheers Didier PH Martin ---------------------------------------------- Email: martind@xxxxxxxxxxxxx Conferences: Web Chicago(http://www.mfweb.com) XML Europe (http://www.gca.org) Book: XML Professional (http://www.wrox.com) column: Style Matters (http://www.xml.com) Products: http://www.netfolder.com Cheers Didier PH Martin ---------------------------------------------- Email: martind@xxxxxxxxxxxxx Conferences: Web Chicago(http://www.mfweb.com) XML Europe (http://www.gca.org) Book: XML Professional (http://www.wrox.com) column: Style Matters (http://www.xml.com) Products: http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Future XSLT expansion, Tom Myers | Thread | RE: Future XSLT expansion, Tom Myers |
RE: Future XSLT expansion., Didier PH Martin | Date | Re: Future XSLT expansion., David Carlisle |
Month |