[exsl] rationale (Was: Re: 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format