[Hpr] Direction idea for HPR website
ken.fallon at gmail.com
Wed Apr 3 05:25:07 PDT 2013
On Tue, 2 Apr 2013 20:29:41 -0400
dg <dg at deepgeek.us> wrote:
> Hey, Ken & Crew,
> I recently finished the latest HPR news. When Ken started on "maybe we
> don't need wordpress," I got thinking.
> I think wordpress might not be the best idea for HPR because, IMHO, it
> is a collaboration system for authors. Our network is a crowd of
> people doing their thing in audio and publishing on one site.
> So I think an HTML solution is in the cards. But I think we have an
> opportunity to make excellent use of a relatively new technology that
> might be well suited to our community. I'm thinking of XML conversion
> templates, AKA XSLT.
> Chew on this, we have a series of podcasts, but we supply each in
> multiple formats because our community wants different formats for
> different reasons. Each format we have, we want to have both an atom
> and an rss feed.
> So, I think we should look into whether or not the following is
> possible. I think we should have the HPR submission system create one
> detailed XML file. I mean **ONE** file. Couldn't we then create a
> series of XML conversion templates (XSLT's?) We could have one for
> each kind of feed for each of our supported formats (IE, atom & RSS
> for each of ogg, speex, mp3, and opus in the future, ) because, after
> all, feeds are a type of xml file. Our webpage itself can be an
> xhtml or html file, so that can be generated also. As a matter of
> fact, we could have a XSLT file to create a regular webpage, a
> visually impaired webpage (high contrast, etc.,) and also one for
> text browsers (for those uber-geeky emacs and lynx users amongst us.
> Dates in the XML file can be selected for both most recent as well as
> current and future-inclusive feeds if desired (heck, imaging ken
> queing up a whole week in one batch, and having XML and XSLT just run
> HPR for a week, WOW!)
> To summarize my query, as I only know the very beginnings of XML
> theory, I want to ask if it is possible. Can we have the HPR
> submission system create one detailed file, and then have XML
> conversions do all the heavy lifting for us?
> Yours, seriously, geekily, & philosophically,
> Hpr mailing list
> Hpr at hackerpublicradio.org
Yes that is in actual fact the plan. That **ONE** file of which you
speak is an Atom XML file. It supports exactly the functionality you
describe and it's //entry elements are designed for merging multiple
sources together. We would take an ATOM XML file from our more
technical hosts and use the upload form to generate one for those (as
yet) without the knowledge or desire to create one themselves. In fact
the whole changes on the back end is driven by this overall plan. And
as you say it would be possible to drive the whole thing from a file
based collection (although it doesn't rule out the option of having a
database). We have discussed this on some shows and were the archiving
of the mail lists working, I could point you to those as well.
In the intervening time, a bit of realism has hit my enthusiasm for
XML/XSLT. This is partly due to the experiences Dave and I had parsing
the RSS feeds of Linux podcasts and also partly how difficult it is to
create a consistently compliant RSS file on HPR. Admittedly the RSS spec
is loose, (AKA Horrible), but the experience has seriously dented my
faith in technical ogg/podcasters let alone anyone else been able to
provide a valid xml file all the time.
However time will tell. The first step would be to see if our
contributors can produce shows according to the specifications, which
currently are defined here:
However none of that changes the fact that the shows are only a
component of the website. Yes a very big component, but to be honest we
could operate with just a rss feed and no website at all. The website
is there to support and build the community. Reading what HPR is
about, seeing when the next event is, getting more information on how
to record, leaving feedback, etc.
The easy part is injecting the XML/Atom or XML/RSS from a known good
format, be that xml or database tables, into the site. We can do that
with HTML5/CSS3 or we can do it with WordPress or any other CMS for that
matter. What is not trivial is supporting all browsers, devices,
accessibility, and all the 'cool' stuff people expect.
Going the Wordpress route we open ourselves to more attacks and we need
to trust that wordpress team. I don't have a problem with that but the
fact is that we would need to bring in plugins from 3rd parties that
have less than stellar respect for privacy and who's code would not be
as audited as a base wordpress site would be.
However the bigger problem is, as RowingGolfer pointed out, our HTML
code on the site is a complete mess. The problem is the site itself but
also the show notes. Dave and I are going through each of the show
notes to clean them up and in the process I was thinking of wrapping
the shows in the fancy new HTML5 Article element
(http://html5doctor.com/the-article-element/) which would map nicely
from Atoms Entry Element
(http://tools.ietf.org/html/rfc4287#section-4.1.2). If the field
doesn't map, then the amount of XSLT you need increases dramatically.
This is important as it determines what elements we allow in the show
notes. For example a <h1>. If we decide to make the show notes
HTML5/CSS3 compliant, then anything we transform it to also would need
to support HTML5/CSS3 or it will turn out that while the //article
elements are valid, the site as a whole would be invalid.
So even to assist in checking that the show notes are correct would
necessitate a basic HTML5/CSS3 wrapper page. So if that work is been
done anyway, why not just have a HTML5/CSS3 site based on some nice
of the issues of portability and would give us a basic site that
respects privacy while giving the accessibility features that we desire.
So in short: yes xslt is cool.
Can anyone recommend a nice HTML5/CSS cc-by-sa theme ?
More information about the Hpr