The biggest problem is that HTML parsers must reparent elements. This would make discerning in-scope namespaces difficult. Separately, xmlns forbids elements with undeclared prefixes. Those sorts of restrictions won't fly in HTML as she are spoke. The best one could hope for is a spec that defines an xmlns subset that would work in both HTML and XML. - Rob Tim Berners-Lee <timbl@w3.org> wrote: > >On 2009-03 -02, at 01:23, Henri Sivonen wrote: > >> I'm not suggesting change [to RDFa] for the sake of change. My >> interest here is keeping things so that text/html and application/ >> xhtml+xml can be consumed with a single namespace-aware application- >> layer code path using the infoset representation API of the >> application developer's choice given a conforming XML+Namespaces >> parser for that API and a conforming HTML for that API. That is, I'm >> interested in keeping the software architecture for consuming >> applications sane. I think language design that implies bad software >> architecture can't be good Web Architecture. The single code path >> architecture also precludes taking branches on version identifiers >> and such. >> >> Concretely, given the software architecture of Validator.nu (which >> is SAX2-based and pretty good architecture in the absence of RDFa), >> I couldn't add RDFa validation with the xmlns:foo syntax without >> either: >> 1) Resorting to bad software architecture by implementing notably >> different above-parser code paths for text/html and XML. >> OR >> 2) Changing text/html parsing to map xmlns:foo to infoset >> differently from how already shipped Gecko, Opera and WebKit have >> mapped xmlns:foo in text/html to infoset (by considering how they >> map to DOM Level 2 and then by applying the DOM Level 3 to infoset >> mapping). > >Yes, the goal of having one code path on top of a namespace-aware API >is important. > >When one has a namespace-aware API, shame not to have the namespaces. >What are the arguments against implementing xmlns: recognition in >*future* HTML5 parsers? > >(I can't imagine that there are a lot of people who have accidentally >used the string xmlns: inside attribute names in the past. :) > >There would still be a need for kludge code for legacy browsers, but >with time some applications would just propose to work with XHTML and >HTML in newer browsers. (For example, things which need other new >features anyway). Others would keep the kludge code in forever. But >it would be a huge step forward toward solving this issue. > >Tim BL > > >Received on Friday, 6 March 2009 01:41:41 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:01 UTC