Subject: RE: [xsl] [exsl] Re: Draft 0.1 - call for comments (longish...) From: "Kevin Jones" <kjouk@xxxxxxxxxxx> Date: Mon, 26 Feb 2001 12:13:47 -0000 |
Jeni Tennison wrote: > >I see the route being: > > user-defined extension functions (in XSLT or other languages) -> > community standardisation -> > W3C standardisation > I guess we differ here. It not clear to me that the first step is required although XSLT based user-defined extensions would at least be portable if it is. I don't think we have a strong enough case either way but it looks like an expensive option to assume we do need user-defined functions. > >I also think that implementers will be more sympathetic to >implementing a standard means of extending their implementations than >to committing to constantly adding these functions themselves. But I >may well be wrong on that. That's an interesting question. I wonder if it would make sense to try both of these approaches simultaneously to see which is actually more successful in practice. > >David Rosenborg also made a good point about the performance >implications of *only* having standard extension functions - the more >functions that you add to a language, the heavier-weight the >implementations and the slower they get. Allowing user-defined >extension functions keeps it fairly clean and light. Speaking for myself I can't see this problem. Normally these functions have little to no impact other than increasing the code base. It would have the effect of increasing the amount of work required to create a new processor which may not be a good thing. If I implemented an extension function it is going to perform at least as well as a user defined function and very likely a lot better. This is simply because the implementer have access to the processor internals which normally allows them to implement a better algorithms to solve the same problem. > >On the complexity front - certainly adding a couple of extra elements >and adding the opportunity to define snippets of code in functions >rather than in templates adds a little to the complexity of XSLT, but >I don't think it adds a huge amount. Functions are just like named >templates, really, they're just called in a different way. But I'm >thinking about complexity for users here, but perhaps you're thinking >for implementers? I am rather implementer centric on these issues. I just see the number of issues that are being raised by user defined extensions and equate that into complexity. There appears to be a lot of overloading on existing semantics with special rules everywhere. XSL is so full of exception cases at the moment that I would like to see the language getting simpler not more complex in any form. > >Just to make it clear - are you opposed only to XSLT as the extension >language, or to any language? Pretty much the use of user-defined extensions in any form. I see XSLT like SQL, a language not designed to handle this issue. When I initially looked at the problem XSLT defined extensions looked the obvious solution. Following the recent discussions on the subject I just find it difficult to see how this can be achieved in a way that really improves XLST, i.e. elegantly with good performance and without additional complexity. > >Cheers, > >Jeni > >--- >Jeni Tennison >http://www.jenitennison.com/ > Regards, Kev. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] [exsl] Re: Draft 0.1 - ca, Jeni Tennison | Thread | Re: [xsl] [exsl] Re: Draft 0.1 - ca, Jeni Tennison |
Re: [xsl] [exsl] Draft 0.1 - call f, Francis Norton | Date | Re: [xsl] Call an XML with Paramete, Ruben Inoto |
Month |