Scripting News for 7/17/2007

OPML 2.0, day 2 

I’ve gotten some feedback about the OPML 2.0 spec, hopefully there will be some more as people review it one more time before it’s frozen. See yesterday’s post about why it’s time to review it now.

Don Hopkins wants two things: 1. I should define flatdown in the spec and 2. It should be possible to include elements of OPML 2.0 in other XML documents.

I may attempt both of these items, but I can’t do it quickly. An informal definition of flatdown could be done in a few minutes. A rigorous one might take a lot longer (which is why I didn’t try to define it in the spec in the first place). It appears in the definition of the expansionState element, which is an element specifically for people who are implementing outliners, and those people surely know what flatdown means (informally, it means moving to the next node down from where you are, regardless of structure). But even an implementer of an outliner could ignore expansionState and all that would happen is that the user would have to re-expand the outline as he or she likes it. It’s a convenience for the user, basically. Certainly not crucial to anyone’s implementation of OPML.

Item #2 is something I definitely want to do, because I want to use OPML 2.0 elements in an RSS 2.0 feed, in fact, I already am doing that in the feeds for the TwitterGram site. For example:

http://mp3.twittergram.com/rss.xml

You’ll notice that each item has an ownerId element, in the opml2 namespace, which is declared at the top of the feed to point to the OPML 2.0 spec.

I decided to approach it this way to avert a flamewar or Pilgrimish rants that there are 18 different versions of OPML. The worst that could happen here is that the feed for the TwitterGram site has an error, and so far, no one has reported this particular difficulty (Harold Gilchrist did work with me on another unrelated problem).

I’ll write some more about this use of OPML 2.0 as a namespace in a bit.

Instant indexing 

I just searched on Google for “flatdown opml” and it returned the article I wrote 15 minutes ago.

In 1997 I wrote about Just-in-Time Search Engines and how important they would be. Back then I was thinking about overnight indexing. Now we’ve got instant indexing. Knock that one off the to-do list, it’s done.

8 responses to this post.

  1. I agree with Danny Ayers’ post yesterday. May I suggest that the ‘docs’ element be changed so it can contain multiple URLs. This can either be through a space-separated list of URIs or some kind of sub-element. This way an outliner which uses multiple ‘docs’ can point to them. More interesting, though, is the possibility that could be had for translation in to other formats.

    This could be broadly equivalent to the ‘@profile’ attribute in HTML. Some potential uses: marking up a copyright status for an OPML file – eg. by including a URL of a Creative Commons licence.

    It is quite feasible that a triple-store database like OpenLink could be used to store OPML data, and making it easier to mark extra semantics inside an OPML file would be very useful. It is something I have been working on behind the scenes.

    Reply

  2. Tom, we’ve been over this many times over many years.

    Net-net, I don’t think this is a good way to go.

    Reply

  3. Actually, I’ve just thought – you could actually implement the @profile functionality in OPML using just one URL in ‘docs’.

    Well, on the things I use and care about, I’d say OPML 2.0 is good to go!

    I have a RELAX NG XML schema that I wrote recently for OPML 2.0 which I will publish soon, and keep aligned with the OPML 2.0 specification. It conforms pretty damn close to the specification as described at the moment. It works very nicely with the Namespace Routing Language for producing valid OPML documents in editors like OxygenXML and validating existing documents.

    Reply

  4. Dave,

    In Subscription lists, what about adding an optional attribute for channel image … imageURL.

    This attribute would add a very a useful visual when presenting a list of subscriptions to a podcast listener.

    Reply

  5. http addresses are referred to a few times in the spec. They could be local file server addresses, too? Thinking about use on intranets, especially for inclusion — process documentation and stuff.

    Reply

  6. Hey Dave!

    How did you get indexed by Google so fast?

    was it perhaps RSS? Does this mean that google has a HUGE listener for all RSS feeds all over the world? What actually is going on? I’m curious to know.

    Reply

  7. I’d say the current state of the spec looks pretty good now.

    The only slight problem I have is how the link attribute might or might not be pointing to opml in order for it to be treated as an inclusion or a web browser link.

    It seems too arbitrary and requires the outliner application to work something out to determine if the url is opml or html. Especailly since so many scripting languages could be generating the opml and might end in say, .php or .cgi etc. (or, in our case at podcast.com, a simple url with no extension eg: http://opml.podcast.com/1817 which describes the top podcast audio folder owned by a user called ‘rooty’)

    I’d say that to avoid future confusion (which can so easily spoil how people consider and use a spec) while we have an opportunity to, as you finalize the 2.0 spec, why not simply say:

    type=include points to a opml url for inclusion

    and

    type=link SHOULD point to a web browser link url ONLY UNLESS (for backwards compatibility) the url ends in .opml

    I personally think that without this, things could get a bit ‘fuzzy’ for developers of opml reading applications and also opml publishers.

    Having said that, why not even go so far as to deprecate the url attribute in favour of opmlUrl, htmlUrl and xmlUrl (despite the fact that they are *all* xml urls ;p)

    OR even let the type attribute define what is at the url, without doubt.
    eg:
    type=link url=#a web browser url#

    type=rss url=#an rss feed url#

    type=include url=#an opml url#

    It kind of makes more sense, but I suppose we still need xmlUrl and htmlUrl for times we want an outline element to point to more than one url for things like an rss feed’s url, and the web site it came from.

    I also like Harold’s optional attribute for head/image ( like rss’s channel/image ) – I think that would be great. People like pictures ;)

    OK. Now bear with me here:

    Finally, without stirring the pot too much at this late stage, I still have a BIG voice in my head screaming for the OPTIONAL usage of the type attribute as a MIME type defined in RFC 1341.

    This would solve SO many issues and also present SO MANY opportunities for developers to create hugely rich applications and fuel the adoption of the format.

    eg:
    type=application/rss+xml url (or xmlUrl) points to an rss feed (as used in the link rel html head tag)
    type=application/opml+xml url points to opml
    type=audio/mpeg url points to an mp3 file
    type=image/jpeg url points to an image
    type=video/mp4 url points to an mpeg4 encoded video

    etc, etc…

    WHY?

    I think these days there is SO much more multimedia out here on the web, that it makes sense to use the actual MIME type so that people can use OPML 2.0 to organise, discover and navigatel the ever increasing amount of multimedia out on the web, without expecting to find it encased in HTML on a web page.

    The addition of this OPTIONAL usage of the type attribute, at this stage in the game would REEEALLY give OPML2.0 some incredibly powerful legs in today’s rapidly growing world of multimedia. IMHO.

    In fact, the applications I could think of right now, if this were the case boggles my mind!! Wow! What a platform! Richness!

    Welcome to web 3.0 ;p

    Reply

  8. Dave, the only thing I’m really suggesting at this point in is you give OPML 2.0 a namespace, to make the format more a part of the web. With “using OPML as a namespace” you’re only halfway there, see Bruce’s comment yesterday.

    All this would require in OPML docs is:

    <opml xmlns=”http://www.opml.org/spec2″ …>

    Without this you’re asking for “Pilgrimish rants” – OPML used on its own would be different format than OPML used in other XML docs.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 60 other followers

%d bloggers like this: