On 2008-02-03 16:28, you wrote: > Daniel Aleksandersen wrote: > > On 2008-01-30 23:32, you wrote: > >> Hi Daniel, > >> > >>> I am curious about the status of the required <div> container when > >>> including xhtml in text constructs. Wi[ll] it be changed to become > >>> optional instead? > >> > >> There's no ongoing effort to revise the Atom syntax format, so > >> assume this <div> will be required in the forseeable future. > > > > That is a shame. > > This is the wrong way to think about the div container. Think of it as > defensive markup. It's there to help prevent things that consume your > feed breaking or mangling your content. In itself, it's not flaw, or a > bug; it's not even a wart.
It’s a «safety net» for people who do not want to read the specifications of what they are creating? > > Then maybe I should include an entire XHTML document structure. That > > would make more sense than including XHTML fragments contained in a > > div element. (That unnecessary div really bugs me, for some reason.) > > You can check the archives if you have time. I don't know if anyone > that worked on Atom likes it, but the div is considered necessary to > robustly transfer chunks of XHTML inside Atom. I tried doing that before posting my question. I could not phrase my search query right. :-/ > [The problems the div solve aren't specific to Atom btw] > > >> It's probably not a bad idea to use the HTML namespace as the > >> default within your text construct, like so: > >> > >> <summary type="xhtml"> > >> <div xmlns="http://www.w3.org/1999/xhtml";> > >> <p> > >> This is a <em>summary</em> paragraph. > >> </p> > >> </div> > >> </summary> > > > > Are there any downsides to defining the namespace in the atom:feed > > element instead of repeating it troughout the document? > > Probably yes. For example, that assumes downstream processors will > remember to copy over the namespace from the root element and not just > extract whatever is inside the content element. Or someone will paste > in prefixed XHTML fragment into a non-prefixed document, and something > will output garbage because it doesn't handle namespaces prefixing of > XHTML properly. Of course XML+XMLNS aware code isn't supposed to behave > like that, but if we had such things as the general case, we wouldn't > need the div workaround to encapsulate XHTML names to begin with. > > Given that you've looked at this, considered it, and come up wanting - > a broken content-type workaround - it's probably better for you to > assume a lack of robustness in kind from your consumers, and emit what > the Atom spec says you must emit, irregardless of how you feel about > it. Like I said, it's defensive markup. What I wanted was to question the standard. To me it appears broken. Flawed, at least. …I should probably use <archive xmlns="http://purl.org/syndication/history/1.0"/> as well? What is the point of xmlns:prefixes="URI" attributes? Really, why make a standard if no one follows it? -- Daniel Aleksandersen <[EMAIL PROTECTED]>
