[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] [exsl] Re: Draft 0.1 - call for comments (longish...)
I am sure I speak for everybody on this list in thanking Jeni for the effort and skill she has demonstrated in putting together this document and facilitating the preceding discussions. Thanks so much. However, following on from comments by Dimitre Novatchev I am finding it hard to see the how user defined extension functions can be implemented in XSLT without adding a considerable amount of complexity to a language which is currently (1.0) simultaneously both very elegant and very confused (confusing?). One of the strengths I see in the XSL model is that procedural business logic programming is banished to XML generation code far away from presentational and transformational work. Introducing complex procedural programming through the backdoor would in my opinion be a mistake. There are many general-purpose languages much better suited for this work. On the other hand, the restrictions placed on XSLT writers in the current standard means that finding solutions (quite often obscure) to common transformation problems has become the overriding activity of this list. The W3C model of making it easier to write non-portable extensions appears to me as a short term patch that will create as many problems as it solves. If the goal is to ease the difficulties faced by in the every day use of XSLT via extending the power of XPath (in this case via XSLT based XPath functions) I can think of two alternatives ways of thinking about the problem. Instead of standardizing on a way to write extension functions define a set of functions that can be used to solve most common issues. This can be published as a community standard so pressure can be added to vendors to conform or die! The Saxon extension functions would be a good starting point. This could be seen as a proactive force on the next XSLT/XPath standards to improve community feedback. Currently something the W3C *appears* to perform badly due to its closed standards process. This may not give the immediate gratification of being able to just write your own extensions but I think it would do a lot to keep down the complexity and increase the portability and maintainability of XSLT. It is not completely clear that a standard set of extension functions would cover most currently difficult transform cases. Working this out would be a useful exercise in trying to decide if user defined extensions functions really are going to add value. I am assuming not, as so many problems on the list appear to be common. If, as reported, XPath is going to become part of the DOM model in the, drawing on the parallel between DOMs and databases, it begs the question of how this problem is solved in the DBMS community. The logical equivalent of an extension function is a stored procedure. Here you are often given access to the underlying data structures (via cursors) to create whatever function you want. In a similar model for XSLT processing it would be the DOM provider who would define how to create extension functions (probably your DOMs native language equivalent of plug-in modules). It's interesting to point out that stored procedures have there own language and environment (I believe primarily because of the efficiency issues). XSLT like SQL appears to me to be simply not suited to creating user defined functions. This model would then be more of the DOM Extension API something like the Java JNI. In summary I could quite easily back a standard set of extension functions without any issues. I think long term we will see implementation of DOM based extension API's based around some standards. Preferably both models could be used so that common solutions don't have to be implemented by hand while you also get the ability to write your own extensions for those really tricky cases. I think that writing extension functions in XSLT appears initially very attractive (as apposed to Java, etc) but in the bigger scheme of things it appears to me to be a short term hack that will significantly add to the complexity of XSLT without improving the language. I am assuming that it is self evident that having implementations provide a set of commonly needed extension functions is far preferable than everybody writing a version for themselves. I am not really saying that the proposal won't work as laid out. More that I don't think user-defined functions in XSLT are a good idea at all. I understand the current restrictions in XSLT that you could solve with user-defined functions but think better solutions to these restrictions are to be found elsewhere. Either way the use of this list to promote what the XSLT community really needs has got to be one of the most important steps taken is recent months on XSLT. Kev. (An implementer and user of XSLT) XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|