RE: Future XSLT expansion

["Didier PH Martin" <martind at netfolder dot com>]

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@netfolder.com
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@netfolder.com
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