hpr-knowledge-base/hpr_transcripts/hpr0629.txt

Episode: 629
Title: HPR0629: RSS 2.0 Specification with iTunes namespace
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0629/hpr0629.mp3
Transcribed: 2025-10-08 00:10:42

---

Hi ladies and gentlemen, today's episode is on RSS specifically the new test feed for
Hacker Public Radio.
Hi everybody, my name is Ken Fallon and I've been working on getting a compliant
RSS feed for Hacker Public Radio.
We have a feed that is failing validation at the moment by the when it was generated.
I don't think the 2.0 specification was ratified when we started using the feed.
So I won't update that, but because there's 11 gigabytes of information sitting behind
that feed, I don't want to do anything hasty with it.
So I'm using this episode as an opportunity to ask you the dear listener to do some testing
with us as a way to kind of give back for all the hours of entertainment or pain, depending
on your point of view, which you've had via their Hacker Public Radio network.
All the links will be in the show notes, but they are most likely the Hacker Public Radio
dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot
dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot com dot
m and this of course for anyone thinking of a hplur topic, this is an ideal topic because it's something that I've had to do anyway, and then I did some research on it.
And there's an output, so now I'm making a podcast about it in the tradition of HPR.
If you do something that might be of interest to hackers recorded, because it'll make a good show.
Well, I don't know if this one is going to be making good show, but it'll make it show.
Okay, if you want to know about a little bit about RSS or better yet,
RSS is nothing more than a format of XML, then there is a good site called w3schools.com,
which are, you know, which run into various different tutorials on lots of different topics,
and HTML, and they start very simple, and then they work the way down.
And it's quite good, actually. So if I read out there,
what XML stands for, first of all, XML stands for Extendable Markup Language,
much like XML, but it's designed, or much like HTML, and it's designed to carry data.
It is tags are not predefined, you can define your own, and XML is designed to be self-descriptive.
In a nutshell, what all that means is text files are a good way for transferring information
between one system and another, but the format that computers understand
can be difficult for humans to understand.
In XML, that's sort of half a mark where you can create tags,
which are things between square angle brackets, so greater than sign,
and another greater than sign, similar to what you see in HTML, HTML.
And there are actually quite, you know, there can be range from quite simple to very,
very, very complicated, and you have other things like SSD files,
which describe the various different tags and formatting of them, so.
But the show isn't about that, the show is about RSS, which is one particular brand of XML file.
And the one that we're specifically interested in is the one that is going to be a hacker-public radio
that I don't know, for slash test.xml. Now, with XML files,
you can have different formats, so you can design your own XML format,
like that two that I use at work, for instance, are EDI specification
and a TV any time specification.
There are both two specifications for describing video files.
The specification, video ingest, video content into systems,
so they have things like title, actor, author, and whatever.
And to go along with those, you have a text file, so it's like a template that you dump in data,
and then you have another file called an SSD, which describes what's allowed in each of the different fields.
So it can be self-describing in that respect.
Now, we're going to go, and we're going to examine another specification,
which is the RSS specification, which believe me, is a lot simpler.
And an RSS file is nothing more than an XML file,
so you start off your XML by declaring your file, by declaring what version it is.
And let me just say at this point, if you're doing XML,
if you're doing any text files, you're as well converted to UTF-8,
which is a format that allows extended characters, foreign characters,
left to right characters, and things like that.
So your XML version, so use UTF-8.
So the first line of this new feed has XML version 1.0,
which to be honest, I'm not 100% sure it's correct, but because in the following line,
we're going to use a thing called namespaces, which allows you to take certain components
of other XML standards and prop them into your own.
And that support was an addition to XML version 1,
but I think the point is mute because XML, all the XML implementations,
kind of support namespace anyway, so let's move on.
Okay, the first line of our actual RSS, we have the XML line,
the second line is RSS, space, and the version is equal to 2.0.
And that version just tells the reader that this is a version 2.0.
And then we define our namespaces, so our XML NS is double colon, Atom.
So any time that we have a tag with XML colon NS, Atom,
that will mean that we're going to be not using the namespace from this standard,
we're going to be using it from the other one that we're going to refer to.
So for example, if you had two namespaces like namespace,
Foo, and namespace bar, and both of them had the tag, the tag called, I don't know, title.
And you wanted to make a differentiation between both of them,
you would say in your XML file, you would say Foo, colon, title equals this,
and bar, colon, title equals something else,
such allows you to differentiate the two, kind of think I'm losing people on here.
But then you stay with me, stay with me please.
Here we go, here we go.
The first element, the first element is channel.
So we have required elements, retired channel elements.
So within the RSS, we have a section called channel.
So we have an opening bracket, and then at the bottom we have the very last line of the file
is angle bracket for RSS to close the RSS part.
And the next second last line is angle bracket for RSS channel to close the channel part.
So anything you open, you have to close just so you know that.
So I'm not going to labor the point, but you can figure that out through the course of this
that any element or that we have open that has to be closed.
So the first element, an element is something between a square bracket,
an angle bracket, I mean to say, an opening angle bracket and a closed angle bracket
is called the title.
And in the specification it says, the description, the name of the channel,
it's how the people refer to your service.
If you have a next HTML website that contains the same information as your RSS file,
then the title of your channel should be the same as the title of your website.
So therefore we used in the RSS feed and in the old one, the title is hacker public radio.
The next required element is link.
And that is a URL to the HTML website corresponding to the channel,
which in our case we're going to point to hackerpublicradio.org forward slash about that PHP.
I thought, well, if somebody's going to link to that and the press the URL
rather than going to the hacker public radio main site, which is nothing more than the HTML
ized version of the XML feed, why not redirect them to the about page,
which has more detailed description about who we are, what we want.
Please and please want to be wanted now.
And the next line in the new file is the Atom link,
which is taking the link reference.
And remember what I was telling you before about having two elements of the same name,
one is link, which specifies it's coming from this RSS version, two specification.
And the next one is Atom colon link, which means that the specification for this one
is coming from the Atom specification, which has been declared in the second line.
I don't know if you're following me.
Bear with me, you're doing well.
Let's go.
All right, and that has a specification, which requires a href and a rel section,
which is self and the type application RSS plus HTML.
And the whole point of that is the reason I put that in there is because it's a recommendation
by the RSS advisory board.
And what they have done is they've gone out and tested a lot of HTML feeds
and have given recommendations.
And their recommendation is that you can identify, an RSS feed can identify its own neural
using the Atom link element within the channel.
This link must have a rel attribute of self and a hrel containing the feed URL
and may have an attribute type of application RSS plus HTML.
So what I did was I popped that in there just to make it compliant.
The link to this will also be in the show notes and makes very, very interesting reading
if XML is your thing.
And as it's turning out, I think everybody is beginning to realize that it is my thing,
sad though that maybe.
And then we go on to the next one, which is another element.
But in this case, we're going to be using the iTunes name space.
And we're going to be using the iTunes sub title.
So what they have done is they have defined additional name spaces.
So to have a valid iTunes feed, you're going to need title, link, copyright, and pop data,
which all come from the RSS to specification.
But of course, they've gone ahead and created their own author, their own block, their own category,
their own image, their own duration, explicit keywords, new feed URL owner, sub title, and summary.
Now, I have looked at their specification and they say, well, if they don't get their own iTunes author,
then they're going to use the author as defined here or this field as defined there.
And to be honest, I've gone through a few of these and there are a few things like the explicit tag.
I don't even think that's needed because RSS had support for an original, their own rating scheme.
The duration won.
Yeah, I can see how that might be handy.
But everything else pretty much could be covered by the RSS 2.0 specification if you wanted to.
But anyway, we live in a world where apparently loads of people of iTunes and OK, fine.
So what I've put in there is the iTunes sub title, which is, quote, a daily show hosted the community.
We're going to have to fix that.
What I meant to say was a daily show hosted by the community on topics that are of interest to hackers.
And then I close that tag. And then we have the description, which is coming from the RSS 2.0 feed specification.
And that is Hacker Public Radio is a podcast that releases shows every week they monitor through Friday.
Our shows are produced by the community and can be on any topic that are of interest to hackers.
So that is pretty much self explanatory.
Then we have the language, which is EN-US, which I also think is self explanatory.
And then we have a section, which is the iTunes categories.
Now, iTunes, since we started this feed, changed the category structure.
Limitering is quite a lot, actually, but there you go.
So the categories that I and my infinite wisdom have decided that HBR falls into.
Is technology tech news and education training.
Now, please, please, please feel free to go to the link in the show notes, especially the one about the iTunes specification.
And at the very bottom it gives you a list of categories.
And to be honest, I think HBR has had a show that has fallen into every single one of those categories.
But unfortunately, the category is only on the channel part.
So how this specification works is there's the channel bit and then you have items.
So we're still in the channel bar, which describes Hacker Public Radio itself.
And the items are the shows themselves.
So what I wanted to do was, well, I would have liked to have categories under the show that host could decide on their own, but they can't, obviously.
And then the iTunes image, and we have a link to HBR underscore feed.png, which is the big logo.
And if anybody knows who's done that logo, can you please get back to me because I really think it's a cool logo and I'd like to get the source files for that.
Okay, and then we have the iTunes explicit tag, which is set to yes, because you can't conceivably think of any reason.
I know some people, yeah, I know let's not go into it, but it is some people have shows that might be considered by others to be explicit and vice versa.
I need to be on the safe side.
If you don't, if Apple and their infinite wisdom, if you set that to no and Apple in there and went for the wisdom decide that no, no, no, it is explicit then you're going to get in trouble.
And then knock your feed out.
Anyway, keywords, community radio, tech interviews, Linux Python, software freedom, and I kind of came up with these.
I did a sort on all the words that were used in the entire feed, and that's kind of what floated to the top, aside from plateau, for some reason.
And that's the end of the, that's, that was an iTunes keyword.
And then we have the copyright section, which defines the copyright, which is creative comments, attribution, non-commercial share, like 3.0 license.
And then we have a managing editor, which there has been in the recommendations, there's, there has been, you know, recommendations about what that should be or not.
But for our purposes, it's, it's kind of, I put it to feedback at nosbam.checkupublicradio.org, and then in brackets, HPR feedback.
And then we have iTunes owner, where iTunes have their own format rather than reusing that, they have iTunes owner, which then has additional elements iTunes name, which is HPR Web Minister, iTunes email,
admin.checkupublicradio.org, and then close the tag.
And then we have the same information, again, in the Webmaster tag, which is coming from the RSS 2.0 specification, and that's admin at nosbam.checkupublicradio.org, and then brackets HPR Webmaster.
And the idea here is that the, okay, the feedback and the admin go to the same people, but, you know, in the fullness of time, perhaps that might change.
And as, again, as I say, this whole section that we're talking about here is still about HPR Webmaster.checkupublicradio as a, as the umbrella organization, as opposed to the individual shows.
So, then we have the pub date, which is in this, well, don't get me started on pub dates, to be honest, on date formats.
This is, this format is in the RFC 822 specification, which has the day of the week, three letters, comma, space, the digits of the month, space, three letter, month, space, the year, space,
the hours, minutes, seconds, separated by call on space, and then the time is odd.
Personally, I think that's, now you know what I'm going to do, I won't go into it.
Yeah, just this thing about dates and their specification, because if this was, you know, if this was in French, for instance, that wouldn't make any sense, because Friday, no Friday from bananas or November from whatever.
I personally think that it should always be year, month, day, hours, minutes, second, micro seconds, and then times all.
But that's my, that's my thing, okay.
And the generator is VI, in this case, it might change that.
And that is just a tag to say what application was used to generate this feed.
And then we have the tag docs, which refers back to the RSS board and gives a list of the specifications so that later down the line, if somebody else wants to say, oh, where do I get the specification for this feed, they can open up that link, and then they will be given access to the specification for that file.
So therefore they can write their own reader, which is kind of cool.
Now, I put in a few things here for caching networks, and I know in the recommendations, they say they don't really work, but why not?
Why not put them in?
About the time to live to 3,200 seconds, which is approximately 12 hours, I think.
So that, although it doesn't work, it does tell cache networks that, you know, when you're, when this was generated last, whether they need to allow the need to keep it in the cache before checking again.
And that's the importance of pop date as well, which I didn't kind of go into was the publication date of the, of this feed.
So if this feed in our case is only generated once a day, then a cache network can go, okay, well, this is only fed once a day.
It's been published there midnight, so I'll grab that feed and I won't check again for another 12 hours.
So, so then, yeah, less bandwidth used by everybody and everybody's happy.
And I'm also using the tag skip days, which is day Saturday and day Sunday, because we don't produce shows in Saturday and Sunday.
So we're telling these networks that they can skip those days.
And then we have the image, which has the URL of the small image and the title is hacker public radio.
And we have the link for the image, which linked to about that PHP.
And then we have the description, which is the hacker public radio, all microphone logo.
And the thing we do is specify the height and width on the image.
So that whole section has been about hacker public radio, the network.
And then we will have 610 by the time you hear this or more, actually, by the time you hear this item sections in the main feed.
Right now, this XML file has been carefully molested by myself.
And so it's not going to change.
So if you are testing this field, pop it into your application that you used to download podcasts in the bash potter.
I've checked it on the bash potter, so I know it works there.
And then, you know, see if stuff works.
And I'd appreciate your feedback.
And yeah, that would be great on that.
Then we go into the item sections.
And the item sections will be one for each different episode that we produce.
And then the item section we have, the title, which is episode number column, whatever.
How I found how we found Linux, which happens to be the one that I'm using here.
Now, I want to make a change here.
So rather than the link, then we have a link section for the item, which is if the pod reader supports it, the pod capture supports it, then there will be a link on that episode itself.
So what I want that link to do is to go back to the correspondence page.
So the hosts page of all their shows that they've done.
And they will be listed there in that because this section is about the host.
Whereas the other section is about HPR. You kind of get from drift.
So if your pod reader supports a hacker public radio, then link will go for hacker public radio there.
But when you click on your section about this item, then you click on that.
You get to the correspondence page.
So kind of that's where I'm going with that whole concept there.
And then we have the description.
Now this is interesting.
And this prompted me to, what prompted me to do this wasn't, was an email by on the HPR mailing list that names will be changed to protect the instant.
It's saying that the links didn't work.
So, you know, links to, if you want to get the org version click here was actually said.
And if you go to the website, then when you click here, you are redirected to where the org version was.
However, that stripped out in the feed that we currently have.
So after doing some investigation, I realized that the only place in the whole thing, in the whole RSS feed where you're allowed to have HTML encoding is in the description field of the item tag.
So not in the description field of any of the section above that describing HPR section, the only one is in the title description.
Otherwise, it will fail.
And not only are you allowed to, it has to be escaped HTML.
So instead of the greater than sign, it has has to be a percent GT, a percent SP, a percent quote semicolon, you know, that sort of stuff.
So it was just in the end of the world.
But what it does mean, actually, is that now your show notes can contain HTML, which might be nice.
But that said, I don't want people going nuts and not because I will have to check it.
I don't want cross-site scripting or something.
So we'll try and keep it simple to, you know, both strong emphasis, you know, bolder time, like links, lists, that sort of thing.
You know, the basic HTML for beginners type stuff.
And so that's, that's about that.
But we'll, I'll talk probably more on HPR news about, about show notes later on.
Then we have the iTunes summary tag.
And then that will be the, the name, how I found Linux, a short podcast and how I found Linux.
And then the author here.
And this will be the email address of the author who has generated this here with the word no spam dash in the middle.
And that is, I'm not sure if that's required or not.
And then we have the comments, which will redirect to the comment page for this episode, which is also a new addition.
And then we have the pub date, which is going to be the same as the pub date for the main feed.
But obviously that will stay fixed, whereas the pub date for the main feed will change from day to day to day to day.
And that is also used by cash and access to see whether this is a new show or whatever.
Then we come to one of the most useful iTunes ones, which is iTunes duration.
And that is something that I can get when I'm uploading the shows.
I can run a program.
I think socks, supports, or FFMpec will see.
To get the duration of the podcast, which is kind of nice because it would be nice to have something on the main page.
Now over 200 hours of programming, you know, that would be kind of cool.
And also so that people will know how long the shows are.
And then we have the iTunes explicit yes tag.
I'm not sure if, you know, maybe later on down the road will have that, you know, optional for a particular show.
But as I don't use iTunes, I don't think, you know, if that's going to change, that will be on feedback from somebody else.
So there we go.
And then we get to the meat and potatoes, which is the enclosure space URL.
And this is the actual thing, the points to the media that's coming down.
And it is it should be called for such a public radio for such apps.
And in this case, it's test on MP3.
But in the case of this being an automatic feed, it will be the show itself with the length, which is the fall size of the show.
But it's a bit confusing that length there one would have thought that it was the length of time of the show.
But anyway, it's the, it's the file size.
And then we have the type, which is audio for session, MPaq.
And then we get to the GUID, which is a global unique identifier, which in our case is HPR column for force,
I could probably radio.org.eps, force-test.mp3.
But that could be anything.
A pod reader is only supposed to refer to that as a string of characters that is unique.
So, but it makes sense for us to use it because they cycle up.
And then we would have the end of that item.
And then we would have the next item and the next one and the next one.
And then we'd have the channel.
And then the end of the channel and the end of the RSS feed, and that's it.
So basically, what I want you to do is stop listening to this episode now.
Copy it into your podcast reader, hackerpublicradio.org, for such test.xml.
See if I'm the hacker public radio section that you're redirected to about.
See that, see if you get a logo.
See if you can see all the keywords and stuff that I've said.
See if the emails pop up. If they all work, what emails you do have.
Make note of things that you can't do and things that you can't do.
See if the HTML works on the episode itself.
See if you're brought to the correct correspondence page when you click on the link.
See if you are able to put in a comment and that you're brought to the correspondence comments page.
And of course, make sure that they all you place.
It's the episode that I've attached on here is actually episode one of HPR.
So have a listen to that as well.
As I say, this feed will not be changing.
And it's not going to be staying alive for very long.
So if you're listening to this show in 20 years, well, welcome back. Welcome to the future.
So there you are.
And then if you could, you know, have a look, make screenshots of whenever I take a photo of stuff.
If it doesn't, if it doesn't make sense.
And if you could get back to me, if you run into any problems and if you could get back to me,
even if you don't run any problems, run into any problems, the feedback is admin at hackpublicradio.org.
Or better yet, better yet.
If you could, and I think everybody should do this.
If you could be so good as to nip over to hackpublicradio.
And under the contact page, you'll see a section called mail list.
If you could click that link, which is HTTP colonforstashforstash,
hackpublicradio.org, mailmanforstashlistinfo, forstashhpr, underscore, hackpublicradio.org.
Then you will be brought to a page where you can join the mailing list.
And don't be afraid, it's just a list of other people who listen to this network.
And if you could pop in your feedback there, that would be great.
Okay, that's going to do it.
I'm going to do nothing more with this episode and slap on the intro and the outro.
And that should be that.
I hope you have a nice day.
And I look forward to your feedback.
Thank you very much.