This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] Re: [exsl] Re: Draft 0.1 - call for comments (longish...)
- From: cutlass <cutlass at secure0 dot com>
- Date: Mon, 26 Feb 2001 13:44:42 +0000
- References: <20010226112417.22388.qmail@web6301.mail.yahoo.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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