Graham wrote:
Just to address the Pace. I support it, but I don't think it's necessary to add it to XML data types, since "normally [this would] mean that the "atom:content" element would contain a single child element which would serve as the root element of the XML document of the indicated type", which is where you put the namespace, so you'd never need a wrapper, so we can drop the attribute and assume its value is "none".
I quite agree.
For XHTML, there's almost no reason not to add the div, so we might as well drop the attribute here and use assume its value is "dispose".
For XHTML, there's almost no reason to add a div if it's not needed or wanted by the author.
I'd expect my feed and entry titles not to be block-content but rather inline content, so a div wouldn't be an appropriate container regarding its structural meaning.
People wanting containers to carry their XHTML namespace declarations (in order to produce prefix-free documents) can choose among the inline-level span or the block-level div elements. If their content is already in a container (e.g. a single paragraph summary), they can use it as the xmlns holder.
Moreover, not requiring a div container discards at the same time the questions such as what to do with its attributes? should we state that the div container MUST NOT have any attribute other than the XHTML namespace binding? etc.
The spec could still provide examples and suggest such a use of an almost-meaningless container, without mandating it.
This does not mean either that the "could validly appear within a XHTML div element" wording is to be removed! but it should apply to the Text Construct element. It could as well be more precise (using a SHOULD) depending on the text construct element, saying the atom:title element SHOULD contain XHTML text and markup that could validly appear within an XHTML span element: the span content model is a subset of the div one so this doesn't interfere with the preceding MUST. It would only be an indication of which kind of content (inline or block) is expected.
I must admit I still can't understand why the div container was introduced an how it has survived 'til now... (this is NOT a criticism, just a remark; I'd be glad if someone could point me to the thread(s) where it has been discussed and adopted)
-- Thomas Broyer
