[I appologize that this comes late. I was ill last week.]
I'm also still not convinced about this one. It was introduced with a very good motivation, namely that it would increase the chance that namespaces would be used correctly. After the changes, what I understand is left is the following:
Everybody has to use an XHTML <div> in every atom <content> of type "XHTML", just to make sure that Sam (any others?) can realize his dream of "atom without namespace prefixes".
This despite the fact that those that want to avoid any and all namespace prefixes can use a <div> on their own if they want. As Sam explained, the <div> in that case would be part of the content. That's true, but while adding a <div> formally changes the content, it doesn't actually change the content, because <div> is just a dummy wrapper, in particular if there are no other attributes than the default namespace declaration.
On more general terms, I have observed different choices of how different namespaces get put together over the last three if not more years. For the simple case of "namespace B in namespace A", a variety of choices, with a variety of reasons, has been proposed.
On the outer side (namespace A), the choices range from "foreign namespace stuff can be inserted pretty much anywhere where it makes sense, just put it in" to "we have a '<foreignstuff>' element, anything from another namespace has to go in there".
On the inner side (namespace B), the choices again range from "any B element can be used" to "only a wrapper element can be used".
As an example, SVG tends to high explicity on both sides, for the inner side, see "included document fragments" (http://www.w3.org/TR/SVG11/conform#ConformingSVGIncludedDocuments), for the outer side, see <foreignObject> (http://www.w3.org/TR/SVG11/extend#ForeignObjectElement). Most of the motivation for this explicitness in SVG comes from the fact that without being clear on coordinates/placement/size, things won't work.
Looking at these cases, it seems to me that what we are doing with <div> is really thinly motivated (no need for any special information such as coordinates), and is also in a way abusing <div>, which was created to indicate divisions in HTML documents, not to serve as a throw-away default namespace holder in foreign document formats. Actually, instead of <div>, we could as well define that we use <body>, or we could even define that we use something new like <wrapper>. Because as it turns out, while this element is in the XHTML namespace, it's never part of an XHTML fragment that an XHTML processor would see.
At 05:05 05/02/16, Anne van Kesteren wrote:
>
>Tim Bray wrote:
>> PaceXhtmlNamespaceDiv
>> This is tough. There are some people who are really against this and who aren't moving. On the other hand, there are way more who are in favor. Reviewing the discussion, the contras are saying that this is sloppy and unnecessary and if it solves a problem, that problem really shouldn't be there, but they don't seem to be saying it's actively harmful. But the people in favor are arguing that this will reduce errors and improve interop. Also, the Pace was changed in midstream.
>> Also, Paul thinks we will get feedback on this from out there in the IETF.
I'm not sure I understand this sentence. Does Paul think that we will get feedback in the IETF to put it in anyway, so we better already put it in? Or that we'll get feedback to take that out in the IETF so we can as well leave it in for the moment? Or what?
Regards, Martin.
>> DISPOSITION: Borderline, but accepted.
>
>I'm still not sure how it would improve interop, especially since the place the namespace can be defined is optional. I do not think those "Planet aggregators" would handle the following correct for example:
>
> <atom:entry xmlns:atom="..." xmlns:b="http://www.w3.org/1999/xhtml";>
> <atom:content type="XHTML">
> <b:div>
> Foo <b:br />
> Et cetera.
> ...
>
>Also, this restriction can be avoided by using |type="application/xml"| or |type="application/xhtml+xml"| I assume? (Although that is probably not valid for the TITLE or SUMMARY element (it should be).)
>
>
>--
> Anne van Kesteren
> <http://annevankesteren.nl/>
>
