[
Lists Home |
Date Index |
Thread Index
]
David Carlisle wrote:
>
> > On what basis do you make this inference?
> the purpose of putting an attribute (or element) into a namespace is to
> [b]e able to refer to that attribute or element name unambiguously from
> other contexts. That's the _only_ thing that xml namespaces do: give
> a method of allocating globally unique names.
>
> so if you use an attribute in a namespace then the reason for doing that
> (should) be so you can use that attribute in different contexts.
> this is why xlink attruibutes (and xml:lang etc) are namespaced.
I can see a justification for the converse proposition:
"If an attribute is intended to be applicable to elements in
any vocabulary, then it must be namespaced." That makes sense.
But not the other way around: "If an attribute is namespaced,
then it may appear on any element" simply doesn't hold true.
So *one* reason for namespacing an attribute is so that it
can be used on elements from foreign namespaces. I don't see
anything in "Namespaces in XML" that asserts that to be
the *only* reason.
> > This specification makes no assertions as to the proper usage of such
> > attributes. The combination of the namespace name and the attribute name
> > uniquely identifies the global attribute.
>
> in other words the phrase "global attribute" and "attribute in a
> namespace" currently mean the same thing. which is why several people
> have commented that unless you furher qualify something, a change that
> puts unprefixed attributes into the namespace of their elements
> will make them global attributes.
That's entirely true. However, after re-re-reading [XMLNS]
A.1 "The Insufficiency of the Traditional Namespace" and
A.2 "XML Namespace Partitions" several times, I'm coming
to the conclusion that this entire section is essentially
meaningless. At most, it indicates a "Best Common Practice."
You could for instance change the third clause in A.2 to read:
"The Per-Element-Type Per-Day Partitions"
Each type in the "All Element Types" partition has an associated
(Traditional) Namespace in which appear the names of all atttributes,
qualified or otherwise, that are provided for that element.
The combination of the attribute's name, attribute's namespace name
if present, the element's name, element's namespace name if present,
and the current day of the week (in the local timezone)
uniquely identify each member of this partition.
and it would not change the meaning of the Rec one bit.
> Thus Simon's and your assertion that putting these attributes into a
> namespace does not make them global is wrong.
Right. It makes them global attributes because "global attribute"
is defined in [XMLNS] to be synonymous with "attribute with a
namespace name". It also makes them "proctological" -- a term I just
made up, which means simply "must have a colon", and which has exactly
as much semantic impact on applications as the quality of being "global",
that is to say, none at all.
In fact, I suspect that the Best Common Practice of using
unqualified attribute names for "semantically local" attributes
(as in XSLT, etc.) has more to do with avoiding proctological
attributes than with making a lexical or Infoset-level distinction
between "semantically local" and "semantically global".
Since [XMLNS] doesn't provide a mechanism for defaulting attribute
namespaces, using unqualified attribute names saves typing.
If the Rec had gone the other way, specifying that unqualified
attributes inherit their namespace name from the containing element,
the Best Common Practice would have been to namespace-qualify
all attributes.
> It would of course be possible to change more of the namespace spec and
> change the definition of a global attribute. If that was done carefully
> the objections might go away but without seeing all the proposed
> changes, who can tell.
I'm pretty sure you could remove the definition of "global attribute"
altogether and it wouldn't make a bit of difference. You could
certainly take out that nonsense about how "An XML namespace is a
collection of names" without harm, and there's probably a lot of
other meaningless prose in there too.
--Joe English
jenglish@flightlab.com
|
