- From: Robert J Burns <rob@robburns.com>
- Date: Thu, 22 May 2008 18:33:44 +0000
- To: "Charles McCathieNevile" <chaals@opera.com>
- Cc: "Aaron M Leventhal" <aleventh@us.ibm.com>, www-tag@w3.org, "public-html@w3.org Group" <public-html@w3.org>, public-xhtml2@w3.org, "wai-xtech@w3.org WAI-XTECH" <wai-xtech@w3.org>
Hi Charles, I don't want to let this thread get out of hand, so let me just focus on a specific part that I think we agree on. On May 22, 2008, at 12:08 PM, Charles McCathieNevile wrote: > On Thu, 22 May 2008 12:38:20 +0200, Robert J Burns > <rob@robburns.com> wrote: > > >> Yes, I understand. However, the problem is we need to read the >> recommendation and understand why the recommendation exists in the >> first place. The point is to combine disparate vocabularies into a >> single document. I cannot think why an author would want the same >> attributes (in terms of vocabulary) to appear in two different >> namespaces within the same document. > > I don't think you want the same attribute to be in two different > namespaces. Agreed on this point exactly. However the introduction of the null namespace by implementations (and arguably that reading is easily made in the recommendation itself), does just that: it puts two attributes — both from the same vocabulary and sharing the same semantics — in two separate namespaces (one the null namespace). The same attribute from the same vocabulary — all sharing the same semantics — end up not being in the same namespace (because one is in the null namespace and the other is in a namespace declared and then specified with a prefix). It is completely counter to the purpose of the namespaces recommendation — which in my view is intended to allow authors to easily mix vocabularies. In some cases it prevents authors from being able to take advantage of the convenience of omitting the prefix. In some authoring situations, the author may be better off to always include a prefix (even when it might otherwise have been omitted) because of this error in the spec and in the implementations. My point is that if we introduce namespaces to text/html — and I definitely think we should — then we should not follow the mistake of XML namespaces (both mistakes in the recommendation document and in the implementations). I am arguing that the headaches created by that mistake are much greater than the headaches created by differing on this point with XML namespaces. To do the latter means that authors would first have to alter their stylesheets and DOM handlers to change from existing use of a null namespace to use of a namespace that maps one-to-one and completely with the related vocabulary. It is also possible that someone creative may come up with a way to fix the XML namespaces recommendation and implementations without seriously breaking existing content. Take care Rob
Received on Thursday, 22 May 2008 18:34:36 UTC