W3C home > Mailing lists > Public > www-tag@w3.org > March 2013

Re: Atom vs Polyglot

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 25 Mar 2013 23:50:55 -0600
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Edward O'Connor <eoconnor@apple.com>, www-tag@w3.org
Message-Id: <20130325235055.70dd96d36a35b467d4b8aa7b@bisonsystems.net>
Julian Reschke wrote:
>
> >
> >> I'd look for annotation on HTML that could provide it with Atom
> >> semantics. It really wouldn't require much.
> >
> > Indeed: http://microformats.org/wiki/hatom
> 
> Apparently written down ~3 years ago. Does anybody use that? Are
> there aggregators understanding it?
> 

You'll find hatom code on my demo, I believe it's much older than
that, I think it's the wiki that's 3 years old.  No, aggregators don't
understand it, they tend to ignore text/html as a rule, while text/html
bots give you everything they get, not some pared-down version subject
to wide interpretation from site to site (which is hatom's problem, it
requires its own non-trivial parser).

What I actually use hatom for, is to standardize my CSS from one
project to the next -- the styling for, say, .hfeed differs, but it's
easy to tell what's being styled just by looking at my selectors.  Real
godsend for maintenance, but useless otherwise except for a couple of
plugin doo-dads which can recognize it and do stuff on Ffx, if they're
even maintained anymore.

It was my experience with the uber-hacky hatom which led me to RDFa,
and I did work up a preliminary RDFa vocabulary for Atom feeds and
entries, which I still think is the way to go; also works for CSS but
the selectors get uglier.  When a <form> is marked up this way, the
markup is machine-readable in that this text box changes the atom:title
for this atom:id.  RDFa parses any vocabulary, makes Atom-as-RDFa easy
to work with.

But, not as a replacement for Atom.  As I see it, the whole point of a
feed is to strip out all the presentational cruft (aside from, like,
bulleted lists) and surround the user-generated content with the
relevant metadata -- who posted what to whom when and in relation to
which posts and topics -- in a standardized fashion.

Especially as threads grow, leaving out all that redundant, per-
comment presentational markup and forms saves considerable bytes over
any HTML presentation, to the point where it doesn't make any sense for
HTML to do double-duty with embedded Atom, at least not for feed
aggregators.  It does make sense from a maintenance and machine-
readability perspective, say m2m via annotated HTML forms.

Also to simplify system output, but I do this by caching all that
redundant HTML in XSLT to be generated on the user-agent; this way has
as much positive effect on cache-hit ratios as embedding Atom in HTML
(doesn't matter if the hit is for the presentation or the feed, it's
the same entity), minus the bandwidth hit, with the added complexity of
a single XSLT stylesheet, no big whoop.

-Eric
Received on Tuesday, 26 March 2013 05:51:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 05:51:09 GMT