Re: [xml] xsltproc, xsl:version, and alternate prefixes

[Daniel Veillard <veillard redhat com>]

On Fri, Jun 01, 2007 at 10:09:03AM +0200, Tim Van Holder wrote:
> Daniel Veillard wrote:
> >> I checked the specification (1.0, 1.1, 2.0), and it's quite clear that this is 
> >> processed in the usual way regarding the namespaces specification.  The 
> >> output file seems to be generated without any problems, so I'm unsure why 
> >> there's any output claiming an error.
> > 
> >   the version attribute should not have a namespace
> >     http://www.w3.org/TR/xslt#stylesheet-element
> > 
> >  And the rule is set in the preceeding paragraph:
> >  http://www.w3.org/TR/xslt#xslt-namespace
> > 
> >  "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. The presence of such attributes must not change the behavior of XSLT elements and functions defined in this document."
> > 
> >   so basically per the spec the 
> >     xs:version 
> > attribute is ignored, leading to the compilation layer complaining about it
> > being missing.
> 
> I'm sorry Daniel, but I disagree with your interpretation here; the spec
> lists a few attributes, including version for the transform/stylesheet
> element, and the paragraphs before it do indeed say:
> 
> ""
> 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. The presence of such attributes must not change
> the behavior of XSLT elements and functions defined in this document.
> Thus, an XSLT processor is always free to ignore such attributes, and
> must ignore such attributes without giving an error if it does not
> recognize the namespace URI. Such attributes can provide, for example,
> unique identifiers, optimization hints, or documentation.
> 
> It is an error for an element from the XSLT namespace to have attributes
> with expanded-names that have null namespace URIs (i.e. attributes with
> unprefixed names) other than attributes defined for the element in this
> document.
> ""
> 
> What I read this as saying is:
> - a namespace-prefixed attribute from a namespace other than the XSLT
>   one is allowed, and the processor is free to ignore them (and it can't
>   even complain about them if the namespace is unknown to it)

  agreed

> - a non-namespace-prefixed attribute on an XSLT element has to be one
>   of those specifically specified

  agreed

> This says NOTHING about ignoring xs:version, provided that xs is defined
> as a prefix for the XSLT namespace; the paragraph about ignoring
> attributes specifically says "any attribute NOT FROM THE XSLT NAMESPACE"
> (emphasis mine). So my reading is that using a prefix on XSLT attributes
> for XSLT elements is allowed but not required (except that you may only
> drop the prefix if the attribute is specifically listed in the spec for
> that element).

  And my reading is that on all the examples there is no prefixes.
And where a prefix is needed the spec write it so, while it does not for 
the attributes from XSLT on XSLT element.

  "An xsl:stylesheet element must have a version attribute, ..."

does is NOT equivalent to

  "An xsl:stylesheet element must have a version attribute or an 
   xsl:version attribute, ..."

as a spec writer I know that allowing multiple syntaxes like this is really
something we avoid, what happens when you get both attributes ? What if 
one says "1.0" and the other "2.0" ? 

  http://www.w3.org/TR/xslt#element-syntax-summary

never use qualified attributes. The non-normative DTD version does not 
either. 

I'm pretty sure this was changed due to user feedback, but could not
find where.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/