[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[exsl] rationale (Was: Re: [xsl] namespace values)

---

---

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

---