This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Re: namespace values
- To: Jeni Tennison <mail at jenitennison dot com>
- Subject: Re: [xsl] Re: namespace values
- From: Dimitre Novatchev <dnovatchev at yahoo dot com>
- Date: Tue, 13 Mar 2001 06:50:33 -0800 (PST)
- Cc: xsl-list at lists dot mulberrytech dot com
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Jeni,
> I can't point to messages, but there have been several pleas for a
> central library of standard extension elements and functions. EXSLT is
> a response to that. If we misheard, and actually people don't care
> about portability or having that centralised repository, then great,
> we can stop wasting everyone's time. If it's just me trying to
> organise it that you don't like, then fine, I'm very happy to hand it
> over to someone else. If it's the content of the documents that you
> find objectionable, then please say which bits and we can work on
> changing them.
I admire your work and will certainly be glad to use a library of ***standard***
XSLT templates, implementing the various functions you proposed as part of XSLT.
I also will be glad to contribute to such an effort.
However, I would not use any ***library of extensions***, regardless of whoever
created them.
The former is absolutely needed. The latter I cannot risk to accept.
I would probably accept more easily any vendour's extensions, because they are
undisguised extensions and I am clearly aware of the cost I pay by using them.
To summarise -- I am for the functionality, but strongly against changing
the language.
Cheers,
Dimitre Novatchev.
--- Jeni Tennison <mail@jenitennison.com> wrote:
> Hi Dimitre,
>
> > The EXSLT initiative is a good initial set of user requirements for
> > ***the real thing to come in XSLT 2.0***, but not more than that.
>
> User requirements generally don't give solutions to the requirements,
> and EXSLT does. I certainly hope that the discussions we have now
> about the functionality of the various parts of EXSLT will have some
> input into the design of XSLT 2.0 and XPath 2.0, but XSLT 2.0 and
> XPath 2.0 already have sets of requirements. The intention of EXSLT
> is certainly not as a requirements document.
>
> > Anybody has the right to invent a totally new language for
> > processing XML documents. The danger is not to really start thinking
> > this is standard XSLT and mixing the two together.
> >
> > The just published "rationale" proves these concerns:
> >
> > "XSLT processor implementers should implement the extensions as
> > documented, or incorporate third-party implementations of the
> > elements and functions."
> >
> > Nobody can force an implementor to implement/incorporate a set of
> > extensions. EXSLT does not have the normative force of a W3C
> > Recommendation.
>
> What (official or unofficial) organisation you choose to trust to
> define the functions you use is completely up to you. If you want to
> stick with pure XSLT then no one's going to stop you, and I'm
> certainly not planning to take a baseball bat to XSLT UK and beat
> implementers into adopting EXSLT. Though I might bribe them with a few
> drinks ;)
>
> I did wonder about whether the 'should' was too strong, but then I
> wondered what the point was of trying to draw together a standard (not
> standard XSLT, I hope no one's making that misinterpretation, but a
> standard definition of a set of extensions for use with XSLT) unless
> we treat it as something that we can expect implementers to implement.
>
> As Mike said, implementers respond to pressure from the people using
> their software. If I had written 'can if they really feel like it' I
> don't think any implementer would feel much pressure to do so. And if
> they don't implement them, then there's absolutely no point to EXSLT -
> you can't have something that's portable if it's only available in one
> processor, as the multiple extensions in various processors
> demonstrate. So that was why I chose that wording, but please give me
> an alternative that makes you feel better about it and I'll use that
> instead - as I said, that was a first attempt and I'd like to refine
> it to something that everyone finds acceptable and rational.
>
> I can't point to messages, but there have been several pleas for a
> central library of standard extension elements and functions. EXSLT is
> a response to that. If we misheard, and actually people don't care
> about portability or having that centralised repository, then great,
> we can stop wasting everyone's time. If it's just me trying to
> organise it that you don't like, then fine, I'm very happy to hand it
> over to someone else. If it's the content of the documents that you
> find objectionable, then please say which bits and we can work on
> changing them.
>
> Cheers,
>
> Jeni
>
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list