Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 78233 invoked from network); 1 Mar 2000 16:41:27 -0000 Received: from lotus2.lotus.com (192.233.136.8) by locus.apache.org with SMTP; 1 Mar 2000 16:41:27 -0000 Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA24092; Wed, 1 Mar 2000 11:57:07 -0500 (EST) From: Scott_Boag@lotus.com Received: from cammail04.lotus.com (CAMMAIL04.lotus.com [9.95.4.116]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id LAA10980; Wed, 1 Mar 2000 11:40:55 -0500 (EST) Subject: RE: R:R:pathargs problem To: Kay Michael Cc: cocoon-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0 March 30, 1999 Message-ID: Date: Wed, 1 Mar 2000 11:38:49 -0500 X-MIMETrack: Serialize by Router on CAMMAIL04/CAM/M/Lotus(Release 5.0.2c |February 2, 2000) at 03/01/2000 11:43:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > Saxon will currently ignore "xsl:version", but will complain if "version" is > 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. -scott Kay Michael , icl.com> cocoon-dev@xml.apache.org cc: James Clark , Kay Michael , 03/01/00 James Tauber , Tim Bray , 11:25 AM Steve Muench , sca@us.ibm.com Subject: RE: R:R:pathargs problem > 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 attributes. I certainly read this as saying that vendors must not attach a meaning to an 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 "www.ibm.com", 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 no meaning. Except once again, the spec uses a phrase "does not allow" which is 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 an error. Saxon will currently ignore "xsl:version", but will complain if "version" is absent. Mike Kay