Lists Home |
Date Index |
james anderson wrote:
> I do not argue with the spec. I note that the recommendation specifies a notion which is untenable. In order to implement the
> specification one must supplant or contradict its notion in some significant manner.
This line of argument is vacuous and I've managed to avoid getting
irritated by it for some 25 posts now but patience ran out. The
namespaces rec defines a condition it calls "being in a namespace" and
provides syntactic rules whereby element types and atribute names may be
said "to be in a namespace". It notes explicitly that the namespaces
defined in this document differ from the conventional (computer-science)
Similarly, the XML recommendation defines the term "type" and uses it in
a sense that differs quite strongly from the "type" of variables in C
programs, or the lead objects that used to be used in printing. HTML
defines a "hyperlink" which is something quite different from the object
of the same name in Ted Nelson's theory and (separately) in Mac
Hypercard's implementation. Unless recommendations are to start
creating synthetic nonsense names for the formalisms they describe, we
are stuck with the current use of names with (hopefully) mnemonic value.
It is a common but irritating error to assume that a name used in a
formalism is the same as the common usage of that name in some other field.
Elements with no prefix and no default in effect, and attributes with no
prefix, are not in a namespace as the term is used in the formalism
described by the Namespaces recommendation. A programming API which
suggests anything different is simply an erroneous implementation.
A set of related factors that can lead to confusion:
- The empty string "" is in fact a perfectly good URI reference, meaning
"the resource in which I appear"
- it is impossible for the empty string "" to serve as a namespace name
in the Namespace recommendation's formalism, as this empty string is a
used as a signal to *undeclare* the default namespace - and it has been
proposed to extend this facility to undeclare namespace prefixes as well.
- it turns out that in a programming library, it is perfectly reasonable
to use the empty string "" as a signal that no namespace is in effect.
Note that it would also be perfectly reasonable to use a NULL or null
string (in C or Java terms) or some other string that can't be a URI,
e.g. ":". The use of "" for this purpose (which I helped argue into SAX
against those who wanted to use null) is awfully convenient because it
allows a bunch of common things to be based on string comparison
operations. However it is confusing because it supports a fuzzy line of
thought along the lines of 'since "" is the URI ref to the current
document, obviously the unprefixed stuff is in the "default namespace"
of the current document' which, while sweet on the mental tongue, finds
no support in the namespace recommendation.