Michael Kay wrote:
"Yes, I am serious. Programmers have no difficulty with the idea that
data.xml is a different file depending on what directory it is in, or
that Logger is a different Java class depending on what package it is
in; they would have no difficulty understanding that <title>
within an SVG context means something different from <title> in a
MathML context, where the context is defined by an ancestor element.
This would be vastly easier to cope with than the current namespace
machinery. The vast majority of users would never have to worry about it
because most documents use a single vocabulary, so unlike namespaces it
would impose no complexity cost on users who don't need it."
Oh Michael - but this cannot be compared at all! Who am I to tell you that the gist of the matter, when it comes to XML, is not human eyes contemplating a string. Chief design goal of XML is to support XML processing, which ordinarily deals with megabytes, if not gigabytes - there is no "looking" involved. The issue is how to support complex processing which traverses millions of items and must not at any point rely on an "understanding" as it comes easy to a human. When you hint at how bad things have been done and that it could have been done better, you must make sure that the hinted alternative offers the same precision and reliability. When you come up with a name containing dots, I am simply at a loss how you might possibly achieve the precision offered by namespace attributes. To achieve global uniqueness, short strings won't do. Very long strings are out of the question as
element names. So you have the choice of not-too-long identifiers which do not uniquely identify a vocabulary, or long identifiers (URIs) for which a mapping to a short placeholder is required. Namespace attributes keep this mapping cleanly apart from anything else. Would you seriously prefer to shift the mapping into the element names?
Hans-Juergen
Michael Kay <mike@saxonica.com> schrieb am 15:49 Donnerstag, 14.November 2013:
Michael Kay wrote:
"Namespaces account for a very significant chunk of user difficulties
with XML, a great deal of the complexity of specifications like XSD and
XSLT, a similar proportion of the complexity of APIs, and a vast amount
of the code in implementations of these specs. And they aren't
necessary! The world could have managed perfectly well with a convention
where the element name <org.w3c.svg> means "in this subtree, I'm
using SVG element names"."
Michael, you are not serious, are you? Would you suggest that users start to parse names and, depending on whether the name string matches some "convention", infer that something means an apple, rather than a pear?
Yes, I am serious. Programmers have no difficulty with the idea that data.xml is a different file depending on what directory it is in, or that Logger is a different Java class depending on what package it is in; they would have no difficulty understanding that <title> within an SVG context means
something different from <title> in a MathML context, where the context is defined by an ancestor element. This would be vastly easier to cope with than the current namespace machinery. The vast majority of users would never have to worry about it because most documents use a single vocabulary, so unlike namespaces it would impose no complexity cost on users who don't need it.
(But I'm not seriously suggesting that I can change the world, if that's what you mean: there's a difference between knowing where you want to be and knowing how to get there).
