Subject: Re: [xsl] XSLT 1.1 comments From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Wed, 14 Feb 2001 10:53:09 +0000 |
Adam Van Den Hoven wrote: > I'm not sure the problem lies with those who are implementing XSLT > 1.1 processors. The problem exists for those of us who are using > XSLT to produce transformation documents. If I write a document that > I can say is 100% XSLT compliant, then I demand that when I use that > document in a processor that is 100% compliant the resulting output > is exactly as I have specified. With xsl:script, this is not > possible. Because implementors are not guaranteed to implement the > xsl:script tag in a consistent way (if at all), I have no guaranted > that my XSLT document is going to generate the correct > transformations. Unfortunately, it's already the case in XSLT 1.0 that you can write a stylesheet that is 100% XSLT compliant with no guarantee that a 100% XSLT compliant processor will process it exactly as you have specified. For example, an XSLT processor is not required to support disabling output escaping. There are other gray areas where processors have a wide range of allowable behaviours, such as sort ordering. > Where this becomes a big issue is with client side transformations. > One of the big promises of the XML revolution was that I'd be able > to send a client (web browser, PDA, cell phone, ...) one transform > document and several data document and allow the client to do the > transoformation. Now, I expect to have to produce different > transforms for specific target clients. However, I have no realistic > expectation to know whether the xsl parser that is at the client > supports ecmascript, Java, C++, C#, Python or what ever. All of a > sudden we're back to a situation similar to the browser wars (only > worse). Although I can assume that 90% of my viewers are going to > use IE, I'd really rather not have to. Surely, if you don't know which client processor is going to be used to transform your document, then you should write a stylesheet that doesn't depend on extension functions that depend on the client. Or, you should write whatever extension function you want to use in a range of different languages and leave the processor to select one that it can use, with appropriate fallback behaviour in case it doesn't support any of them. [One reason why it would be nice to have obligatory support for XSLT-language extension functions if xsl:script is used - it could provide an ultimate fallback where no other language is recognised.] With xsl:script, at least you can quickly identify the bits of your stylesheet that might suffer from portability problems. There are other parts of XSLT that case portability problems that are more tightly hidden away - it's very easy to design a stylesheet that relies on the error-recovery procedures in a particular XSLT processor, for example. But even with that, we're in a lot better position than CSS stylesheet authors who have to cope with the range of 'support' for that! On the other hand, I do think it's true that a large number of XSLT authors write stylesheets that are designed for IE and IE alone (with or without xsl:script). Think of imgs in HTML - just because you *can* put some alt text for an img to improve portability and accessibility doesn't mean that everyone does. This is bad for them, because they limit their audience, and bad for us, because we can be forced to use particular browsers to view particular content. You can't stop people from writing client-specific pages aside from through banning the things that allow them to do so. The fact of the matter is that we cannot go back to an Eden where MSXML doesn't have msxsl:script, Xalan doesn't have lxslt:component, Saxon doesn't allow extensibility through namespaces and so on. If xsl:script isn't included in XSLT1.1, these facilities will still be there, and if they want to people will still use them. I very much doubt that any implementer will respond to any user pressure to *remove* a facility from their processor. I don't think that anyone can argue that xsl:script means less portability than this current situation. But I'm still not sure on the political questions: should the XSLT Working Group officially ratify the fact that stylesheet authors can define extension functions by agreeing on a method for doing so? Should that method be in the XSLT namespace? Which languages should have bindings described for them within XSLT 1.1 and which without? Which languages should be in the XSLT namespace? Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XSLT 1.1 comments, Tobias Reif | Thread | Re: [xsl] XSLT 1.1 comments (in def, David Carlisle |
[xsl] XPath expression "everything , Fr\id\iric SCHWEBEL | Date | Re: [xsl] XPath expression "everyth, Jiri Jirat |
Month |