This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: XSLT 1.1 comments
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] XSLT 1.1 comments
- From: Adam Van Den Hoven <Adam dot Hoven at bluezone dot net>
- Date: Wed, 14 Feb 2001 09:20:25 -0800
- Reply-To: xsl-list at lists dot mulberrytech dot com
James Clark :
> Adam Van Den Hoven wrote:
>
> > 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.
>
> This is not the case in XSLT 1.0. For example:
>
> - Stylesheets that use extensions (whether extension functions or
> extension elements) are 100% XSLT compliant, but there is not
> guarantee
> that a processor will be able to handle them.
Those extensions do not belong to XSLT namespace. If I decide to use them
then I have knowingly tied myself to a specific flavour of parser. I can
live with that.
If I use tags that are not in the XSL namespace then its not 100% xsl is it.
its XSL + saxon extensions. Its still valid XSL but its not 100% pure BC
grown XSL.
> - XSLT 1.0 also allows extension of output methods and sorting
> datatypes, which are not guaranteed to be supported.
But aren't these in a different namespace or somehow separate from xslt?
> - XSLT 1.0 processors are not required to support
> disable-output-escaping.
Personally, I hate it when a standard says I can use something but doesn't
guarantee that it will be implemented. These things should be avoided when
ever possible.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list