RFC: mtblog and blogcomments RSS module
After the last time, I told myself that I’d never design another RSS module, and certainly not another one that attempts to do the right thing in both RSS 1.0 and 2.0, but it looks like I was lying to me: following along with RSS Blog Browsers and backups meant I needed a namespace for MT-specific fields, and to competely back up a blog, comments. Comments and suggestions are welcome.
Also: draft MT template, also in need of comments.
One issue that I know of but don’t know how to handle: to make RSS work as a Movable Type backup, you need to have the primary category separate from secondary categories (thus <mtblog:primaryCategory>), but I can’t see any (plugin-free) way to produce only secondary categories in an MT template, and if you do manage it, the result will be bad RSS for anything but a backup, since the primary category won’t be visible to anything that doesn’t know about mtblog:primaryCategory. So far the only solution I see is to repeat the primary category in a <category> tag (or in <dc:subject> in RSS 1.0), and require anything importing it to deal with the repeated category.
Entry keywords. http://www.movabletype.org/docs/mtmanual_tags.html#item_MTEntryKeywords
Actually, it looks like entry keywords are part of the mtblog module, they just didn’t make it into the template.
Also, it looks like you’re missing the ending tag for pubDate.
And the encode_xml=”1” should be on the MTEntryMore, not mtblog:extendedBody.
I have hand-crafted excerpts, so I’ll need a place to store MTEntryExcerpt separate from MTEntryBody.
I’m confused about why the radioWeblogPost namespace is defined. You don’t seem to use it.
What are we doing about blogs with multiple authors? I don’t see anything about MTEntryAuthor.
Do we want to maintain last modified date? MT stores it and tracks it, but it’s only accessible via a plugin. http://www.staggernation.com/mtplugins/LastModifiedReadMe.html
(MTEntryDate is the creation date, visible and potentially editable in the GUI.)
MTBlogURL should also use encode_xml=”1”, in the unlikely but not impossible event that the blog URL has an ampersand in it.
MTEntryLink should also use encode_xml=”1”. Plus archive_type=”Individual”, in case the user’s preferred archive type is not ”Individual”.
D’oh. radioWeblogPost actually explains (part) of why it’s so wrong: somewhere along the line I clobbered my example template with the one I was using to test importing into Radio, where I was trying (and failing) to map MTEntryID to radioWeblogPost:ID. And now I don’t see any sign of the original, so I guess we just fix this one instead. Thus the lack of the whole comments section, too. Oops.
Dunno how I missed excerpt, since it’s in the MT import format plain as day. It’ll be in the module as soon as I get home tonight.
MTEntryAuthor should go in dc:creator (in both formats, since RSS 2.0’s author tag is an email address) – I’ll put that in the template in a second.
Last modified date? I don’t think so: MT doesn’t (currently) import it, and if I was writing import code I think I’d set last modified to the date that I imported the entry, rather than the date it was last modified before it was imported. But I’m willing to be convinced otherwise.
And thanks! You do good comments.
This is interesting, but I think a bit of a kludge.
Being an MT user, I think an XML export/import format is a good idea. Basing it on RSS is noble but, what value is stuffing this information into compliant RSS providing? My concern is that such an approach will cause your intent to develop an XML-based import/export format to suffer.
I agree with Mark that an explicit mtblog:excerpt field is needed. Couldn’t the author information be implemented using the dc:creator element?
This raises a bigger issue to your approach though. There is a lot of other data that should be included that is related to the posts. For instance, AuthorNickname, AuthorEmail, AuthorLink. Your proposed format also does not allow for global config settings to be recorded. If I allow comments on *all* of my entries by default should I have to continuously repeat 1 throughout the file?
Might I suggest that in this scenario you prohibit the use of overlapping tags such as category and dc:category? Standardize on module equivalents like RSS 2.0 should have. No sense continuing continuing the nonsense from such a shoddy design. Despite it nefarious beginnings, I take comfort in the fact RSS2 is so loose you can develop your own profile and still remain compliant. http://www.mplode.com/tima/archives/000126.html
Of course it’s a kludge. So what? The reason kludges exist is because they work, they work with what’s available and already in use, and they take little enough effort to seem worthwhile for the benefits. You’re certainly welcome to try to get some traction for a brand new XML format for weblog import/export and browsing, starting from scratch with nothing defined for it and no tools available, but I’ll bet that if Dave asked Brent to throw together a demo browser for a completely new XML format the day before he went on vacation, he wouldn’t have gotten one. And I’ll guarantee that I’ll be bored with the whole thing before the first holy war even starts to wind down.
Excerpt? I forgot it. dc:creator? Already back in the example template.
Other Author* elements? I suppose so, though I’d like to hear that a blog browser author plans on supporting them. As far as backup/importing goes, I’d say that they should be part of the global settings, and although I’m pretty presumptuous, I’m not quite presumptuous enough to tell Ben how he should handle that. Yet. I’m just modelling it on the Radio backup format, where entry-related things go in RSS and global settings things go in native-format files.
I wouldn’t think that you would have to repeat allowComments and allowPings if you want the same value for every entry: doesn’t the existing import routine just assign the blog default value if you don’t specify one?
And then there’s your final ’graph. Do you have any idea how incredibly tiresome the constant political posturing and attempting to curry favor with one side or the other in this whole stupid RSS format war has become? I’m really glad you saved it until the end, because lately whenever someone gets their jabs in in the first ’graph, I just quit reading right there. If you feel you have to do it to cleanse yourself after being contaminated by contact with something Dave did, or if he feels the need to tar all of RDF for the sins of the RSS-DEV WG, fine, but I’d appreciate it if neither one of you said anything important after you start slinging mud, because I won’t ever see it.
Hold on there Phil. I think you’re reading enitrely too much into my comments.
I didn’t realize this was expressly for the blog browsers effort. My fault for not reading your post more carefully. I read ”backup” and ”import/export” and took a different meaning.
I honestly to understand what the point is of blog browsers are really? It has nothing to do with its origins.
There are more then two sides in ”this whole stupid RSS war.” It is stupid and it is over. I’m part of a third group that says RSS-DEV and RSS2 suck in equal parts.
Do you know how tiresome it is to attempt to write reliable RSS software and support it because of this stupidity? I don’t think you apprecaite the lengths I have had to go to compenstate for all it. You want it to end, but when does it end for me?
Hell, if you know why I’m doing it, I wish you’d tell me, because I’m not all that sure ;)
Bits of it are Blog Browser (I’d like to see them construct a full entry from description + mtblog:extendedBody, and maybe display mtblog:excerpt linked to the full post), and parts of it are backup/import/export, but none of that will really matter until or unless somebody supports it, and I’m not sure who that’ll be: Radio doesn’t exactly have extended entries and excerpts (though in some cases you might map either entry -> entry and extended entry -> story, or excerpt -> entry and entry + extended entry -> story), so if you were going from MT to Radio you’d just need to stuff your MT parts into things that Radio can deal with, and if you’re going from MT to MT there’s no point in reinventing the current text import/export format in XML unless you’re going to get some side benefit, which is where we come back around to Blog Browsers. And what’s the benefit of a Blog Browser over a web browser? Uh, dunno just yet. I’m hoping to find out.
So there must be at least four sides, since my camp says ”yeah, they both suck” with a chuckle rather than venom, and then just gets on with trying to do something fun or interesting. Yes, I know how much trouble you’ve gone to, since I’ve been there myself, I just haven’t released the code (because, um, it sucks and not in a very funny way): it’s a pain to deal with multiple data formats in multiple parts of multiple tags, and there is absolutely nothing you can do that will change that or make either set go away, so you just deal with it and move on. Insulting people who did what they thought was best at the time, whichever side they were on and however wrong they’ve turned out to be, isn’t going to do even the tiniest bit of good. Dave has made some sloppy errors and bad design decisions, Rael was apparently not exactly politically smooth and now seems to think that the RDF decision wasn’t so good after all, and so what? None of that affects the pool of data that’s out there to parse, and none of it affects the tools that we’ve got to parse it, and frankly it isn’t even good drama, it’s more like those family feuds that mean you have to have two Christmas dinners, and you can’t seat Martha on the same end of the table as Frank. It’s just tiresome. What is, is.
More RSS junk .. um learning to do
One of these days, I’ll get over my hangup on RSS that I’m dealing with now. Until then, sorry.
More RSS junk .. um learning to do
One of these days, I’ll get over my hangup on RSS that I’m dealing with now. Until then, sorry.