lobitwo.blogg.se - Opml editor online

the standard "RSS" and the lower-case "rss"). Ideally, an OPML-to-XOXO converter would also locate the HTML versions of feeds if the htmlUrl attribute is not there, and vice versa.Īnother implementation note for the version attribute: it's a good idea to check for both upper and lower case versions (eg. If the version attribute is present, it should be used to drop in the relevant MIME-type on the link to the feed. The text attribute may list something different from the title of the linked feed, so that ought to be the value of the hyperlink - one may link to the blog "Epeus' Epigone" and set the text field as "Kevin Marks". What should be done with an RSS feed node? Since it is almost the primary use of OPML, it would probably be advisable to optimize any conversion effort to deal efficiently with feeds.

Best behavior with title is to grab the RSS/Atom feed and infer it from that, rather than relying on the OPML file to give it to you.

title - The title of the linked feed (eg.

description - The description field from the linked feed (optional).

RSS2 - In unofficial usage, this is used to represent RSS 2.0 feeds only (although, according to the spec, they ought to use RSS.

If someone who is an expert on Atom would provide them, and show me that there's some agreement about this from Atom experts, I would be happy to say something about this in the OPML 2.0 spec."

Dave Winer: "I don't know what the valid values are for the Atom version attribute.

atom - In unofficial usage, this is used for Atom feeds of all types.

An example scriptingNews feed, and a Python parser.

This is because it should trigger most people's "RSS" mode in their browser, and then their RSS reader should be able to unpick it using whatever parsing magic is contained within. I'm outputting application/rss+xml as MIME type unless anyone has any good argument to the contrary.

scriptingNews - The spec lists this as being used for Scripting News format feeds.

Despite RSS 1.0 being "just RDF", plenty of people expect it to be RDF/XML, so no Turtle or JSON or embedded RDF-in-HTML.

RSS1 - The spec lists this as being used for RSS 1.0 (RDF) feeds.

RSS - The spec lists this as being used for RSS 0.9x and 2.0 feeds.

version - the particular type of XML feed:.

language - the language of the feed (optional).

Implementation note - Bloglines emits invalid OPML by sometimes including this attribute but leaving it blank.

htmlUrl - the URL of the HTML representation of the feed (optional).

text - usually, but not always, the title of the feed - is user-modifiable, so should not be used as feed title by applications.

The type attribute is set to string rss, implies following attributes: This is usually the behavior of most outliners and is the default behavior of the OPML Editor.

An OPML-to-XOXO parser should ideally take data from the text attribute and put it into a XOXO outline in a standard way.Ī blank type attribute usually implies that it is a text node in an outline, using the text and created nodes. This is standard behavior from the OPML Editor. The text attribute can and does often contain escaped HTML markup (which is really a bad practice, and has led to a lot of criticism of OPML). One should not infer that the title attribute is equivalent to the text attribute (see OPML 2.0 Spec).

If a text attribute is present but not a title attribute, one should infer that the text attribute is equal to the title attribute. Some implementations of OPML break from the specification in providing a title attribute but not a text attribute. Both are reasonably well-defined by the OPML specification, and serve different purposes. There is some confusion over the difference between the text and title attributes. That way, JavaScript could be laid over the top of XOXO outlines to allow them to include OPML outlines or link to them in a way that would proxy them back in to XOXO (etc.). But all OPML-to-XOXO tools ought to point to OPML files (includes, etc.) in a consistent way. One should not infer that something is or is not OPML based on the MIME type, because that's not reliable. There have been suggestions as to whether or not to start serving OPML as: OPML is usually served with a large variety of MIME types including: So, for instance, the "rss" type value tells the processor to look for feed-specific values. Type attribute values extend the standard attribute set of the outline node. There is some formal canonicalisation (in the 1.0 spec and the 2.0 spec) of what individual type attributes do. OPML specifies limitations in a loose way, using the type attribute.