Subject: Re: Status of the <xhtml:div> wrapper

From: Julian Reschke <[email-masked]>
Date: Fri, 01 Feb 2008 20:49:44 +0100

James Holderness wrote:
> ...
> It could even be argued that feed readers aren't actually required to 
> support prefixed xhtml content, so they aren't really broken. RFC4287 
> says very little about the expected behaviour of feed readers. Choosing 
> to only support certain forms of xhtml could well be a deliberate design 
> decision.

Only supporting specific XML serializations is a sign of a clueless 
programmer, that's it. I really can't think of a more polite way to 
state this.

BR, Julian

---

From: "James Holderness" <[email-masked]>
Date: Sun, 3 Feb 2008 01:10:04 -0000

Julian Reschke wrote:
> programmer, that's it. I really can't think of a more polite way to state 
> this.

On the other hand, expending development resources on "features" that your 
customers neither want nor need, at the expense of features that would be 
genuinely useful and appreciated, is a sign of a clueless businessman.

Given that some of the most popular feed readers in use today only support 
specific XML serializations, I would suspect this has more to do with good 
business practice than it has with clueless programming.

Regards
James

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Feb 2008 13:17:10 +0100

James Holderness wrote:
> On the other hand, expending development resources on "features" that 
> your customers neither want nor need, at the expense of features that 
> would be genuinely useful and appreciated, is a sign of a clueless 
> businessman.

To get namespace prefixes wrong requires to either use broken tools, or 
not to understand how XML (+NS) works. You compare the namespace URI and 
the local name, that's it. Programmers that do not get that are 
clueless, at least with respect to XML handling. Sorry. This has nothing 
to do with additional time or resources, just with understanding the 
technology.

> Given that some of the most popular feed readers in use today only 
> support specific XML serializations, I would suspect this has more to do 
> with good business practice than it has with clueless programming.

Defending bugs as "good business practice"? Sigh.

BR, Julian

---

From: Bill de hOra <[email-masked]>
Date: Sun, 03 Feb 2008 15:28:45 +0000

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.

> 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.

[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.

cheers
Bill

---

From: Bill de hOra <[email-masked]>
Date: Sun, 03 Feb 2008 15:47:35 +0000

> to do with additional time or resources, just with understanding the 

I could paraphrase what you said earlier - expecting or demanding 
uniform XMLNS behavior being a sign of a clueless standards advocate. 
But I can think of a more polite way to state it - XMLNS as written is 
set up to cause comprehension and implementation problems, and clearly 
has done so. I think the lesson here is to write better specs, not rail 
against programmers when they are presented with bad ones.

cheers
Bill

---

From: Daniel Aleksandersen <[email-masked]>
Date: Sun, 3 Feb 2008 17:06:12 +0100

On 2008-02-03 16:28, you wrote:
> >> 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.
>

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. :-/

> >> It's probably not a bad idea to use the HTML namespace as the
> >> default within your text construct, like so:
> >>
> >> <summary type="xhtml">
> > Are there any downsides to defining the namespace in the atom:feed
> > element instead of repeating it troughout the document?
>
> 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.
>
> 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-masked]>

---

From: "David Nesting" <[email-masked]>
Date: Sun, 3 Feb 2008 11:07:29 -0800

> point of xmlns:prefixes="URI" attributes? Really, why make a standard if

There are basically three types of tools: XML+XMLNS-aware ones, and ones
cobbled together by looking at examples and writing software that works with
the examples are the big two.  Given the reach of Atom and its dialects,
there will be a *lot* of implementations out there that do things the Wrong
Way.  You can either simplify the standard and limit your implementations,
or give the standard some flexibility and maximize your adoption rate.

But I said three types of tools, didn't I?  The third will be feed
aggregators that want to maximize the number of feeds they can handle.
Given the number of bad feeds there are, pumping these through a typical XML
parser will reject many feeds that they still want to process.  These
aggregators, consequently, may benefit from doing their own parsing,
treating Atom like they treat HTML: tag soup.  These applications may fail
to process some strictly standards-compliant feeds, because they do uncommon
things.  You might argue that this is just them doing things the Wrong Way,
but it's an explicit, conscious decision, not due to their own incompetence.

David

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 5 Feb 2008 06:02:37 +0100

* Daniel Aleksandersen <[email-masked]> [2008-01-31 01:20]:
> I am trying to understand why XHTML fragments must be contained
> within two containers (the atom:summary AND the xht:div
> elements).

I really disliked the mandatory wrapper when the requirement was
added to the spec, but over time I’ve come around somewhat. A
major point is that it makes sure the entire content is contained
in a single child node of the text construct, itself in the same
namespace as the actual content. That guarantee actually allows
taking a bunch of small shortcuts when copying the content
between documents using the DOM API.

So now I don’t mind it so much anymore.

It’s kinda annoying, but you get used to it. In the end it really
isn’t a big deal worth getting annoyed by. There are feed formats
with far more grave imperfections than this one.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Bill de hOra <[email-masked]>
Date: Fri, 08 Feb 2008 22:51:12 +0000

> What I wanted was to question the standard. To me it appears broken. 

If you want to insist on this line, the flawed standard is XMLNS, and 
its idea of a default namespace.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Sat, 09 Feb 2008 09:58:41 +0100

> its idea of a default namespace.

For the record: I agree that some people have problems understanding how 
  XMLNS works. That's certainly a problem with that spec, but there are 
countless FAQs that explain it, and the XML parsers *do* get it right.

The problem is with people not using XML parsers to consume XML, or not 
reading the documentation of the API (local-name vs name in DOM, for 
instance).

What we should have done in the spec is make sure that we have multiple 
examples showing different serializations for the same infoset.

What we still can do is publish a document (IETF Informational, web 
site, whatever) giving and explaining examples.

BR, Julian