This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSLT 1.1 comments


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]