[whatwg] Creative Commons Rights Expression Language

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.
Chris

-----Original Message-----
From: whatwg-bounces@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  
wrong.)
  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
"http://www.example.com/2008/08/namespace# 
".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.

Received on Friday, 22 August 2008 12:19:17 UTC