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

[cutlass <cutlass@xxxxxxxxxxx>]

> 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:  http://www.mulberrytech.com/xsl/xsl-list