Re: Re: namespace values

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@xxxxxxxxxxxxxxxx> 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