[
Lists Home |
Date Index |
Thread Index
]
Greetings,
On Fri, 2 Aug 2002, David Carlisle wrote:
> > that means those attributes aren't in any namespace, and
> > specifically not in the XSLT namespace.
>
> [...]
>
> > I am saying that XSLT processors
> > do recognise those attributes, even though one reading of the XSLT spec
> > suggests they might not have to.
>
> I can't see any reading of the namespace or XSLT specs that could
> possibly suggest that, or any suggest that an XHTML browser could ignore
> the href attribute on xhtml:a.
(1) It is a deduction from the Namespaces spec that attributes without any
prefix are in no namespace. Why? There is nothing which says they
are, and indeed an explicit note to the effect `Note that default
namespaces do not apply directly to attributes'. Thus, the attributes
in the vast majority (surely!) of deployed XSLT code, and the
attributes in much of the code exemplified in the XSLT spec, are in no
namespace.
(2) Section 1 of the XSLT spec says
Thus this specification is a definition of the syntax and semantics
of the XSLT namespace.
And note that it doesn't say, or claim to say, anything about the
semantics of objects not in that namespace.
(3) Section 2.1 <http://www.w3.org/TR/1999/REC-xslt-19991116#xslt-namespace>
says
XSLT processors must use the XML namespaces mechanism [XML Names]
to recognize elements and attributes from this namespace.
This is slightly vague. It doesn't say `must use only', but a
processor would conform to this if it used the namespace mechanism to
attempt to recognise elements and attributes, and found no attributes
(see (1)). What does it do next?
(4) Then
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.
In other words, attributes which are explicitly in other namespaces
are allowed. That's good, because the Namespace spec would be
pointless without this.
(5) Then
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.
That is, no-namespace attributes other than the ones in the XSLT spec are
an error. It is implicitly _not_ an error to have no-namespace attributes
which _are_ the attributes defined in the spec. I can't _find_ anything
which specifies any processing for these elements. Thus this paragraph
permits but does not require processors to recognise no-namespace
attributes, and thus to process the XSLT examples in the XSLT spec.
Of course, we know what the spec _intends_, and as well as the weight of
example document fragments, this is supported half-way through section
2.5, where the spec says:
Thus, any XSLT 1.0 processor must be able to process the following
stylesheet without error, [...]
(though the `Thus' in question is a deduction from remarks about
forwards-compatible processing).
Now, this is all terribly nitpicking. But (a) if the quote in (2) is
to be taken seriously, it does suggest that the XSLT authors rather
expected that no-prefix attributes would be in the element's
namespace; (b) it suggests that namespaces can spring some nasty
surprises (so whom does that surprise?); and (c) that, unless I've
missed something, and the logic above is wrong, XSLT processors are
acting _as_if_ unprefixed attributes are in the namespace of the
containing element (and, I suppose, (d) it might be a nice idea to
legitimise this behaviour as more than just best-practice...).
How's that?
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK norman@astro.gla.ac.uk
|
