cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: R:R:pathargs problem
Date Fri, 03 Mar 2000 16:02:00 GMT
We've come to the conclusion that Xalan is doing 100% the right thing by
throwing an error for xsl:version on an xsl:stylesheet element.

The recommendation says: "An element from the XSLT namespace may have any
attribute not from the XSLT namespace, provided that the expanded-name of
the attribute has a non-null namespace URI."  Note the "not from the XSLT

I could be misinterpreting this passage.  If someone disagrees with this
interpretation, please let me know.  But for now, I think Xalan is doing
the right thing, and will leave things as they are.  (Note that foo:version
will not cause an error to be thrown, providing foo binds to a non XSLT


----- Forwarded by Scott Boag/CAM/Lotus on 03/03/00 10:53 AM -----
                    Scott Boag                                                           
                                         To:     Kay Michael <> 
                    03/01/00 11:38       cc:               
                    AM                   Subject:     RE: R:R:pathargs problem(Document link:
Scott Boag)          

> Saxon will currently ignore "xsl:version", but will complain if "version"
> absent.

Xalan currently throws an error, which is a bug (I'll fix this today).  It
should just give a warning that the version attribute is missing.


                    Kay Michael                                                          
                    <Michael.Kay@        To:     "''" <>,
                                         cc:     James Clark <>, Kay Michael
                    03/01/00             James Tauber <>, Tim Bray
                    11:25 AM             Steve Muench <>,
                                         Subject:     RE: R:R:pathargs problem           

> <xsl:stylesheet xmlns:xsl=""
> xsl:version="1.0">
Relevant statements in the spec:
- An element from the XSLT namespace may have any attribute not from the
XSLT namespace, provided [it has a] non-null namespace URI.

I think it would be legitimate to interpret this as meaning that an XSLT
element must *not* have an attribute that *is* from the XSLT namespace,
otherwise the phrase "not from the XSLT namespace" would serve no purpose.
(But Saxon doesn't currently reject it, it ignores it).

- Vendors must not extend the XSLT namespace with additional elements or

I certainly read this as saying that vendors must not attach a meaning to
XSLT element or attribute if no meaning is defined for it in the standard.
So xsl:version must either be ignored or rejected.

- A processor is free to ignore such [additional] attributes, and must
ignore such attributes if it does not recognize the namespace URI.

Since only the processor knows whether it has "recognized" a namespace URI,
I don't think this sentence adds anything. (Of course I recognize
"", I saw it only last week...)

- In forwards-compatible mode (i.e. if version is not equal to 1.0), if the
element has an attribute that XSLT 1.0 does not allow the element to have,
then the attribute must be ignored.

So if version="1.1", then specifying xsl:version="1.0" is allowed and has
meaning. Except once again, the spec uses a phrase "does not allow" which
thoroughly ambiguous.

- Appendix D, xsl:stylesheet, clearly shows the version attribute as
mandatory. There's nothing that says xsl:version can be used instead.

In short, I think the only question is whether xsl:version here should be
ignored or whether it should be rejected. It certainly isn't acceptable to
treat it as a synonym for "version", and omitting "version" is definitely

Saxon will currently ignore "xsl:version", but will complain if "version"

Mike Kay

View raw message