Re: [xsl] Re: [exsl] Re: Draft 0.1 - call for comments (longish...)

Subject: Re: [xsl] Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
From: cutlass <cutlass@xxxxxxxxxxx>
Date: Mon, 26 Feb 2001 13:44:42 +0000
Once again -- I welcome the initiative to produce a new language for writing extension functions
in XSLT, however there should be no mixing and confusing it with the language XSLT as specified in
the W3C spec.

Dimitre Novatchev.

I have enjoyed lurking in on this conversation ( not too often we get that level of conversation on lists, at least not any more ! ), and the resultant document JT has created is spectacular.

a few comments,( many apologies if they are too simplistic, late or irrevelant)

- writing functions within XSLT is interesting, we are all doing it, but not in a formal recognized namespace, i agree that this is required within XSLT, and then we would get 'all' of Jeni's highly useful functions.

- the parser does/doesn't care if its a xsl defined 'function' are just a series of instructions..... in other words are we looking at a way of emulating reusable components; classes, polymorphism...etc or just a nice way of having a library of functions, and finally we are defining interfaces to external functionality. i think most of the dissent is because the issue of 'scope' has not been determined.

- I think that most of the primary computer languages ( ruby anyone ?) out there needs to mature with respect to all the xml/xslt technologies, for example. why not let the those languages integrate to XSLT instead of the other way around ? for example, I write all my c++ ( classes, etc ) in xml/xsl and use XSLT to transform into its final compiler ready form, but that is directly irrevelant to this conversation. My point is that 'overlap' (think xquery) or ' better ways ' may arise once further integration occurs within the classic computer languages, as the language implementors as things move on.

- Are we looking at XSLT as taking the high road with respect to language integration ? this brings XSLT into different design patterns that have some profound impact to implementation. It is exciting to see XSLT orchestrating many extension functions from various legacy/new applications, but issues such as scalability, performance, real time operation and security quickly come to mind. and security again now that i think about it..............

- XSLT will be for most people, their first entry into functional programming, exciting yes, but unfortunately when one comes from visual basic or c, where u can do ' the whole thing' in one framework,which of course XSLT was not designed for. I am happy with having seperate decoupled components, but must admit that nomenclature can be a bit unweildy and cumbersome when trying to do simple things in XSLT.

-crazy thought #1: if we could define lets say all the functions of a language as external functions for XSLT to use, what would happen ? would we see people coding c purely in xsl/xml.

-we can define a library of reusable functions, written in XSLT, right now ? i use RDF and generate a repository of XSL code, which have some nice OO qualities about them .

-we can define a namespace and define functions as they 'present' themselves to XSLT, right now ? we can all define namespaces and write up a nice validating schmea for our xml

I agree that at one level there is a requirement to have a way of defining 'functions' of XSLT code instead of hard coding XSLT with new functions, but defining external functions are outside the current scope of XSLT, and would be better served as a seperate effort.

cheers, jim fuller

XSL-List info and archive:

Current Thread