This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
[exsl] rationale (Was: Re: namespace values)
- To: Mike Brown <mike at skew dot org>
- Subject: [exsl] rationale (Was: Re: [xsl] namespace values)
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Tue, 13 Mar 2001 09:15:59 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <200103122324.f2CNODb01480@skew.org>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Mike,
> I just lost interest in both the RDDL and EXSLT discussions because
> I apparently missed the posts that said why these things were so
> necessary. What reason do these specs have to exist? What problems
> do they solve? Who should be reading them and building
> implementations around them? No one has bothered to put this
> information in the specs themselves. Look at the XSLT spec, for
> example. There is an Abstract at the top that says exactly what XSLT
> is designed for and how it relates not only to other specs but also
> to more tangible activities.
>
> All right, to be fair, in the case of EXSLT, the justification is in
> there somewhere, but it is in a verbose discussion deep in one of
> the secondary documents, rather than in concisely in the main
> introduction(s). Again, I have great respect for Jeni and all the
> others who contributed, but I don't think I'm alone when I say I
> wish I knew why I should be keeping up with the discussion for it.
I'm naturally very keen that people do keep up with and contribute to
the discussion, and if the price is that I have to write some
rationale, so be it ;) How about this as a starting point:
As XSLT has grown, we have seen more and more XSLT processors being
developed. Many of these processors have built in extensions -
elements, functions, attributes, output methods and so on - that
enable the users of that particular processor to do things that
aren't possible with basic XSLT 1.0.
Each XSLT implemention has placed these extensions within their own
namespace. This means that even in cases where the extensions have
just the same functionality as each other, a stylesheet that uses an
extension from one implementation will not be portable to another
implementation.
The primary goal of EXSLT is to define common extensions within
common namespaces. This will increase portability of stylesheets
that use extensions across implementations. It also acts as a
central location for documentation about the extensions so that
stylesheet authors do not have to learn potentially different
behaviour across different processors.
These documents are relevant to three sets of people. XSLT processor
implementers should implement the extensions as documented, or
incorporate third-party implementations of the elements and
functions. Third-party implementers may implement the extensions as
documented; these implementations should be made available to XSLT
processor implementers. Stylesheet authors should read the document
so that they are aware of the functionality of the extensions that
are available to them.
Contributions are welcome on the extensions that stylesheet authors
would find helpful and the ease of implementation of the extensions
as documented.
Now probably this is too verbose, but I don't know which bit you and
other people need to hear. Perhaps it's just the third paragraph.
Let me know and we can try to refine it.
Note that this rationale is the rationale for EXSLT as a whole, not
just the user-defined function part (EXSLT - Functions). I moved the
rationale for that to the subsection when I broadened the scope of
EXSLT (then forgot to move it back to the introduction when I moved it
out to its own document) and added a lot of verboseness because of
questions off list about why it's designed the way it was. I'll move
it back to the introduction in the next version, but if there are bits
that muddy rather than clear the waters, I'd like to know about them
so that I can refine it.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list