On Feb 9, 2005, at 15:28, Sam Ruby wrote:

Here's the key question.  Consider the following XML fragment:

<summary type='XHTML'><div xmlns='http://www.w3.org/1999/xhtml'>Hey, this is my space, if I want to run a picture of a chair I can. And it’s a <em>nice</em> chair.</div></summary>

Given this fragment, what is the value of the summary? Is the div element to be considered part of the format (and therefore not part of the summary). Or is the div element to be considered part of the summary itself.

The div is part of the summary according to current spec text.

Assume for the moment that it is part of the summary. You can give the author a bit of poetic license and say that this is valid.

It is correct, because a div can correctly be a child of div and the content model of Text constructs is defined to be the content model of div.


If you look at Tim's feed, you will see that a similar approach is used for syndicating content. The validity of that is not quite so clear.

It is correct from the syntactic point of view, although I understand your point that it may not be part of what the ongoing CMS treats as content internally.


Now consider what happens when data is resyndicated (Planet XML, for example). If such tools add a div element,

Your argument is based on the assumption that resyndicators need or want such a div. But why would such an aggregator add the div? While a CMS may successfully engage in string concatenation, because it internally restricts the string serialization of the content, resyndicators cannot rely on a particular serialization and, therefore, must not attempt grab a substring of unparsed XML source and try to concatenate it into an unparsed string template. Since resyndicators need to deal with all of XMLNS, why would they include extra divs that are convenient for string concatenators? The serialization code of resyndicators has to deal with synthesizing namespace declarations and/or namespace prefixes anyway, so I don't see how resyndicators would benefit from adding an extra wrapper.


Now consider what happens if tools that implement the protocol do likewise. Get a feed, modify an entry, and POST it. Over time, you will end up with telescoping divs.

Again, you are assuming XHTML-capable clients want to behave like tag soup concatenators. Why not use type='HTML' for that?


--
Henri Sivonen
[EMAIL PROTECTED]
http://iki.fi/hsivonen/



Reply via email to