It adds an optional CLOUD element to the HEAD element of an OPML
file, supporting publish-subscribe notification. The syntax is
borrowed from the same element in RSS:
Publish-Subscribe Notification
<cloud> is a new optional sub-element of <head>. It specifies a Web
service that supports the rssCloud interface which can be implemented
in HTTP-POST, XML-RPC or SOAP 1.1.
Its purpose is to allow processes to register with a cloud to be
notified of updates to the channel. For example:
Rogers, thanks for kicking off the restart of this list. And thanks to everyone
else for not objecting to the newly stated charter. I'm optimistic about our
being able to get work done this time around. I'm willing to use the tools that
Yahoo provides to keep the list on-topic. There are over 170 subscribers [1],
which is quite a lot, so it's potentially a very powerful community. My hope is
that we can have something like the Berkman-Thursdays group at Harvard Law
School, where we have a high standard of achievement and cooperation and we get
things done. That group organized a conference and hosted over 200 people on two
days. That's what can be done if people have a will to work together.
Anyway, Rogers, I will take your notes on OPML 1.1 and turn them into a document
on the opml.org website. I'm also going to move that site off the UserLand host
and put it on one of the new servers I have running here in the Boston area.
Also once the OPML 1.1 spec is adequately reviewed, I will transfer it to
Berkman Center, as I did with the RSS 2.0 spec, and redistribute it under the
Creative Commons license.
Another area that needs attention is to sort out the common uses of attributes
in different tools. Since this is XML, names are case-sensitive. And there is
even some variability beyond that. The first step should be to survey all the
existing tools, see what they produce and then collate the results. Then, once
that's done, it may be possible to have a simple set of recommendations that
enables more interop between tools. But first we have to see how far apart all
the tools actually are. I'll get the ball rolling on this, unless someone else
wants to take the lead. It's not a glamorous job, it requires that one be
thorough and be good at tabulating information.
Dave
PS: I've cc'd this to the Berkman-Thursday list, in case any of you want to
participate in the restart of the OPML developers list.
>Another area that needs attention is to sort out the common uses of
>attributes in different tools. Since this is XML, names are case-sensitive.
>And there is even some variability beyond that. The first step should be to
>survey all the existing tools, see what they produce and then collate the
>results. Then, once that's done, it may be possible to have a simple set of
Dave: AmphetaDesk was the first application to take the
mySubscriptions.opml of Radio Userland and adopt it for it's own
channel list. NetNewsWire followed thereafter. I haven't been
near AmphetaDesk for a while, but off the top of my head:
* I hate innerCaps, so I write attributes lowercase. I read both.
* I believe you had "text=" as the title of the RSS feed. I
use "title=", but the code converts "text" to "title".
* Any attributes that AmphetaDesk doesn't explicitly use
are read and written as if I did. Likewise, I provide
an API to get at that "unused" data.
I believe I've added two or three attributes not part
of the original mySubscriptions.opml files I've seen:
* filename: internal use for AmphetaDesk.
* date_downloaded and _added. self explanatatory.
* email: the nearest approximation to the
channel's email address, if any.
On Tue, 02 Dec 2003 15:10:11 -0500, Morbus Iff wrote:
> * I believe you had "text=" as the title of the RSS feed. I
> use "title=", but the code converts "text" to "title".
> Another area that needs attention is to sort out the
> common uses of attributes in different tools. Since
> this is XML, names are case-sensitive. And there is
> even some variability beyond that. The first step
> should be to survey all the existing tools, see what
> they produce and then collate the results. Then, once
> that's done, it may be possible to have a simple set of
> recommendations that enables more interop between
> tools. But first we have to see how far apart all the
> tools actually are. I'll get the ball rolling on this,
> unless someone else wants to take the lead. It's not a
> glamorous job, it requires that one be
> thorough and be good at tabulating information.
Per an old thread on this list, I started and posted
an OPML document that contains this sort of info. It
still lives at :
Those folks might want to
take a look to see if I've got things
straight.
Other folks who work on OPML tools: please
post away to this thread RE your OPML usage.
I'll continue to incorporate data posted
to this Yahoo group into the file.
( I have NOT yet added all the new tools,
e.g. agregators et al, that do some OPMLing.
It'll take some time ... )
Plus: expanding the process a bit:
I've opened up a Groove workspace wherein
folks can add to or modify
OPML_Elements_and_Attributes.opml directly
as regards their products' OPMLation.
I'me sending invites to this Groove workspace to
folks who've posted to this Yahoo group about tools
they work on and OPML. If
you don't get an invite, and want to join the
workspace, just drop me a personal email off-group
(Stan@...)and I'll send you an invite.
I'll also be sending invites to other folks who
seem involved in OPML tooldom.
[ If you don't have Groove,
there's a [free for personal use/free for 60 days
of business use] Groove Workspace Preview Edition
downloadable here: http://www.groove.net/downloads/groove/ ]
The Groove workspace can be particularly useful
for indicating your tools' support of the various
elements, attributes, and types. Takes a load of
detail work off me.
>Another area that needs attention is to sort out the common uses of attributes
in different tools. Since this is XML, names are case-sensitive. And there is
even some variability beyond that. The first step should be to survey all the
existing tools, see what they produce and then collate the results. Then, once
that's done, it may be possible to have a simple set of recommendations that
enables more interop between tools. But first we have to see how far apart all
the tools actually are. I'll get the ball rolling on this, unless someone else
wants to take the lead. It's not a glamorous job, it requires that one be
thorough and be good at tabulating information.
>
>
>
When importing OPML files, here's what Bloglines does:
For every 'outline' tag after the opening tag, we do:
We look for the 'xmlurl' attribute. If we find it, we add that as a
subscription. If we also find a 'title' attribute, we use that for the
name of the subscription.
If we don't find the 'xmlurl' attribute, we look for 'text'. If we don't
find 'text', we look for 'title'. If we find one of those, and we do not
find 'url', we add a new folder. All subscriptions found after this tag
and before the closing </outline> are then inserted in that folder. We
only support one level of folders, so nested folders are ignored (but
the subscriptions within them are not ignored).
We consider all attributes case insensitive.
Here's an example of what we output when exporting subscriptions. This
example has 2 subscriptions in the 'Press/Journalists' folder, and two
subscriptions at the top level:
Mark Fletcher wrote:
> We consider all attributes case insensitive.
I think it would be worth having authors catalog what their software
*outputs* as well. It's (somewhat) fine to accept any case tags, but
OPML is specified as XML, so the case should be honored and programs
outputting wrong cases should be considered broken according to the
current spec.
As a soon-to-be producer and consumer of OPML, I have to say this case
insensitivity is disturbing to me; it's not XML. I won't throw a
hissy-fit ;-) but I do think we need to make extra certain that at least
all generators meet the spec.
Jeremy Bowers wrote:
> I think it would be worth having authors catalog what their software
> *outputs* as well. It's (somewhat) fine to accept any case tags, but
> OPML is specified as XML, so the case should be honored and programs
> outputting wrong cases should be considered broken according to the
> current spec.
Clarification: By "catalog what their software outputs" I mean actual
specifications and promises, not just example OPML files their system
outputs. Examples aren't specs.
Excellent. That's exactly the kind of report we need. Since Brent went next,
maybe he could explain how he uses OPML, in a style similar to this explanation.
Since he's not subscribed to OPML-DEV, I've cc'd him. Dave
>Another area that needs attention is to sort out the common uses of
>attributes in different tools. Since this is XML, names are case-sensitive.
>And there is even some variability beyond that. The first step should be to
>survey all the existing tools, see what they produce and then collate the
>results. Then, once that's done, it may be possible to have a simple set of
Dave: AmphetaDesk was the first application to take the
mySubscriptions.opml of Radio Userland and adopt it for it's own
channel list. NetNewsWire followed thereafter. I haven't been
near AmphetaDesk for a while, but off the top of my head:
* I hate innerCaps, so I write attributes lowercase. I read both.
* I believe you had "text=" as the title of the RSS feed. I
use "title=", but the code converts "text" to "title".
* Any attributes that AmphetaDesk doesn't explicitly use
are read and written as if I did. Likewise, I provide
an API to get at that "unused" data.
I believe I've added two or three attributes not part
of the original mySubscriptions.opml files I've seen:
* filename: internal use for AmphetaDesk.
* date_downloaded and _added. self explanatatory.
* email: the nearest approximation to the
channel's email address, if any.
Stan that looks very useful. Could you add Morbus's info to that.
I think people should post their reports to the list, as long as it isn't
overwhelming, and you should merge them into the outline as they become
available.
Also, how about a list of apps you reviewed. Looks like you have "UserLand" and
"JOE." There are now many others, basically all the aggregators do something
with OPML.
Dave
----- Original Message -----
From: Stan Krute
To: opml-dev@yahoogroups.com
Sent: Tuesday, December 02, 2003 3:42 PM
Subject: [opml-dev] Re: OPML 1.1
Hi Dave
> Another area that needs attention is to sort out the
> common uses of attributes in different tools. Since
> this is XML, names are case-sensitive. And there is
> even some variability beyond that. The first step
> should be to survey all the existing tools, see what
> they produce and then collate the results. Then, once
> that's done, it may be possible to have a simple set of
> recommendations that enables more interop between
> tools. But first we have to see how far apart all the
> tools actually are. I'll get the ball rolling on this,
> unless someone else wants to take the lead. It's not a
> glamorous job, it requires that one be
> thorough and be good at tabulating information.
Per an old thread on this list, I started and posted
an OPML document that contains this sort of info. It
still lives at :
> I think people should post their reports to the list,
> as long as it isn't overwhelming, and you should merge
> them into the outline as they become available.
Sounds fine. Info on elements and attributes that
are supported or not supported, and elements and attributes
that a particular tool has introduced, are of interest.
> Also, how about a list of apps you reviewed. Looks like
> you have "UserLand" and "JOE." There are now many
> others, basically all the aggregators do something with
> OPML.
As folks supply info on support/non-support, I'll add that
data to particular elements/attributes.
I'll also add new OPML tools to the list at the node
"further info : OPML tools". In that regard, I've
just added a sub-node for RSS feed readers/news aggregators, and will
add info for starters digested from here:
NetNewsWire imports and exports OPML subscriptions lists.
It doesn't currently understand nested subscriptions lists, but that
will change. (It will both import and export nested lists.)
***Importing
It tries to be as forgiving as possible in what it accepts. It ignores
case. For the name of a feed it first looks at the text attribute, then
at the title attribute. For the home URL of a feed it looks at htmlUrl
then at url.
If an RSS URL doesn't exist, it does RSS auto-discovery to try to find
the feed. (This makes it possible to import blogrolling.com OPML files,
for instance.)
***Exporting
It exports using ISO-8859 encoding, since that's most likely to be
compatible (with Radio and with Windows aggregators).
It sets the following attributes:
text -- name of feed
title -- name of feed (redundancy for compatibility sake)
description -- description of feed
type -- rss
version -- RSS (more redundancy for compatibility sake)
htmlUrl -- URL of home page
xmlUrl -- URL of feed
It's true that examples aren't specs, but beggars can't be choosers.
I'll take whatever information I can get in whatever form. Let's be detectives.
I don't recall Columbo or Sherlock Holmes refusing a clue because it wasn't a
spec. ;->
Dave
----- Original Message -----
From: Jeremy Bowers
To: opml-dev@yahoogroups.com
Sent: Tuesday, December 02, 2003 4:35 PM
Subject: Re: [opml-dev] OPML 1.1
Jeremy Bowers wrote:
> I think it would be worth having authors catalog what their software
> *outputs* as well. It's (somewhat) fine to accept any case tags, but
> OPML is specified as XML, so the case should be honored and programs
> outputting wrong cases should be considered broken according to the
> current spec.
Clarification: By "catalog what their software outputs" I mean actual
specifications and promises, not just example OPML files their system
outputs. Examples aren't specs.