[whatwg] Creative Commons Rights Expression Language
giecrilj at stegny.2a.pl
Fri Aug 22 12:19:17 PDT 2008
12. DOCTYPE declarations have to use prefixes where the corresponding
namespaces are yet undeclared. The same problem affects external CSS. This
effectively fixes the prefixes, making the redirection to the URL redundant.
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Henri Sivonen
Sent: Friday, August 22, 2008 9:51 AM
To: Ben Adida
Cc: Tab Atkins Jr.; WHAT-WG; giecrilj at stegny.2a.pl; Dan Brickley; Bonner,
Matt; Ian Hickson
Subject: Re: [whatwg] Creative Commons Rights Expression Language
Here's what bothers me about namespaces:
1) I need write namespaces URIs several times a day, but the URIs
aren't memorable. Mistyping an NS URI would waste even more time as
bugs than looking URIs up for copying and pasting, so I look them up
for copying and pasting, and it's a huge waste of time.
2) The indirection layer from prefix to URI confuses people.
3) Namespaces not inheriting to attributes confuses people. (I have
had to give a crash course in how namespaces work on W3C telecons and
f2f meetings! Others have had to do it as well. This point is so
confusing that people whose job is working on Web specs get it wrong.
I've been told about a professor teaching a class about XML who got it
4) Instead of comparing names against a string literals, you have to
compare two datums against two literals. That is, instead of doing
"foo-bar".equals(name), you have to do
".equals(uri) && "bar".equals(localName).
5) Removing uri,local pairs from XML parsing context makes it hard
to write the full name in a compact form. Witness the NSResolver
complications with XPath and Selectors DOM APIs.
6) That the prefix is semantically not important confuses people who
go and write uninteroperable software thinking that they should be
comparing the prefix instead of the URI.
7) The design of namespaces considers parsing. It doesn't consider
serialization. Writing an XML serializer that doesn't suck isn't
trivial, and one will spend most of the development time on dealing
with Namespaces. (The prefixes aren't important but people still have
aesthetic opinions about how they should be generated...)
8) Namespaces dropped the HTML ball a decade ago letting the HTML
and XML DOMs diverge.
9) Namespaces stuff their syntax into attributes as opposed to
having syntax on their own meaning that certain magic attribute names
need blacklisting both in parsing and in serialization.
10) Namespaces slow down parsing. (By over 20% with Xerces-J and the
Wikipedia front page!)
11) I've spent *a lot* of time writing code that is Namespace-wise
excruciatingly correct. Yet, Namespaces have never actually solved a
problem for me. My software developer friends complain to me about how
Namespaces cause them grief. No one can remember Namespaces solving a
real problem. It's like feeding a white elephant.
More information about the whatwg