Re: A year-zero strawman.
- It is times like these that I realize, despite my best efforts to
comprehend this stuff, I am utterly clueless and completely confused.
As an "XMLer" that's worked in the corporate IT space developing
solutions his entire professional career and then some, this is not
going to fly. I'm all for exploring RDF in RSS, BUT my feeling is that
it is an intriguing, but highly theoretical, concept. Developers will
look at it briefly, roll their eyes, and say "forget it. I have to
implement something that works now." That does not further RDFs cause
one bit. I am of the opinion that if an RDF-friendly RSS format is too
achieve any type of adoption, it has to be virtually transparent to
the user initially. Overtime as the industry evolves more can be added on.
So with all due respect to Jon, I don't like a lot of the strawman
proposal that was posted to start this thread. (Do you know how many
developers would scoff at having to specifically order tags in an
item?) Not that they don't have technical merit -- they just won't be
accepted in practice under the current climate.
I ask the RDF advocates to consider that in order for RDF (and the
whole semantic web for that matter) to take root, it will have to
"crawl before it run."
I liked Shelley's proposal with Sean Palmer's refinements. Its not
perfect. I don't think folding the Dublin Core in is ideal and the
apparent redundancy of link and rdf:about needs to be clearly
articulated. That said its something I can get my head around and
advocate to others.
What does everyone else think of that proposal? Can we please discuss
it here now?
> The history of support for mod_content (there's now, what, one aggregatorI agree. I checked. Out of over 12,000 feeds just polled there are a grand
> that supports content:encoded out of the box) seems to say that it might be
> a good thing to keep the rich description a bit closer to the core, though.
total of 22 feeds that contain the URI for mod_content. Many of which appear to
be doing it wrong. <sigh/>
> A plain text description that's written purposely as a description isNot to mention the very handy work being done in perl modules and the like can't
> generally fine, but a weblog post with the HTML stripped can be pretty
> incomprehensible - strip out links, <blockquote>, and <s>, for example, and
> it's pretty easy to end up with gibberish. Yes, ideally a tool producing RSS
> would strip HTML intelligently, adding footnotes for links, replacing
> <blockquote> with quotes, and I guess deleting the content of <s>, but most
> blogging tool developers seem to be a long way from having that much time to
be used up inside one particularly popular content generator. So those users
are stuck with waiting for the developer to get around to doing it instead of
being able to use existing works.
> Persuading the developers of RSS readers that can handle the HTML toAgreed and getting them to use mod_content properly would be even better.
> support mod_content would go a long way toward persuading producers to keep
> their HTML out of <description>.
For a developer like MovableType they could simply state that their "except"
input box would not accept HTML markup, just plain text. This would give them
an easy way to push a text-only description element without tag-stripping
hassles. And since the design of MT already supports a two more input boxes the
others could be used inside a mod_content element. Thus the smart work already
done in MT can be quite easily adapted to using the content module. Other
environments, since they don't support these multiple input methods are likely
to have a much harder time of it.