intertwingly

Hi Sam. I had originally registered that domain back when we were creating FeedBurner because we thought, at the time, that we might be able to host a domain where people could contribute and document rss namespace extensions in some kind of common, vendor-neutral fashion. To start things out, we decided that we’d host the FeedBurner extensions at that domain.

Alas, we never really went in that direction, and I didn’t want to gratuitously change the namespace URI for our existing extensions, so that’s why the FeedBurner namespace is the only one hosted on that domain. I’ve done a horrible job of documenting the elements that use that namespace, but basically it’s for elements that FeedBurner adds to the feed while post-processing the feed as a means to preserve the information that was originally present in the feed. For example, there’s an <origLink> element where we stuff the <link> element that’s in the original feed if the publisher has chosen to use FeedBurner’s link re-writing capability to track the clickthroughs to an item.

So, that’s what that’s all about. I’m kicking myself for not documenting the namespace, but I guess it’s not too late. Any questions or comments, please don’t hesitate to contact me. Thanks!

Eric

The only element I remember from that namespace is origLink which Eric mentioned above.  origLink seems to be redundant with the RSS 2.0 <source> element, IMO.  There may be more to that namespace, but I’ve never run into it.

Erm, that’s not domain squatting, Sam: it’s domain parking. The latter is legitimate, the former is not.

origLink seems to be redundant with the RSS 2.0 <source> element

A common misunderstanding.  <source> is only allowed to point to a feed, not an HTML page.  “Its value is the name of the RSS channel that the item came from, derived from its <title>. It has one required attribute, url, which links to the XMLization of the source.”  [link]

Just so it is clear, I am not suggesting that the URI change, or that there be RFC quality documentation, or that the documentation actually appear at that URI.

Here are a few elements that would be flagged as invalid if I suddenly marked this namespace as "recognized":

• channel element: feedburner:emailServiceId
• channel element: feedburner:feedburnerHostname
• channel element: feedburner:feedFlare
• channel element: feedburner:awareness
• item element: feedburner:awareness
• item element: feedburner:origLink

A simple list of element names, permissable locations, data types, and attribute names (if any) would be helpful.  If the list turns out to be incomplete, I’m sure that both of us will hear about it quickly; but any problem that does surface will generally be addressed in hours.

A simple list of element names, permissable locations, data types, and attribute names (if any) would be helpful.

Some of them are kind of documented: emailServiceId, origLink, origEnclosureLink, awareness.

Other I haven’t seen docs for, but it’s fairly obvious how they work: browserFriendly, feedburnerHostname, feedFlare.

<source> is only allowed to point to a feed, not an HTML page.

Agreed, but the reality is that people are pointing to HTML pages from source elements (NewsGator link blogs being one example).

Speaking as a Google employee who has permission to tell you this:

• in feed, feedburner:emailServiceId - child text is integer
• in feed, feedburner:feedburnerHostname - child text is URI
• in feed, feedburner:source - child text is URI
• in feed, feedburner:xmlView - child text is empty, @href is URI
• in feed, feedburner:feedFlare - child text is text, @href is URI, @src is URI
• in feed, feedburner:awareness - child text is URI
• in entry, feedburner:origLink - child text is URI
• in entry, feedburner:origEnclosureLink - child text is URI
• in entry, feedburner:origFeed - child text is URI
• in entry, feedburner:awareness - child text is URI
• in entry, feedburner:formattedDate - child text is text (appears to be a variably formatted date string, but I’m not sure what the possible formats are; I will try to narrow it down)

That’s straight from the Feedburner source code, and I believe the list is exhaustive.  More official docs coming as soon as I can figure out what the hell some of these things are (to be published elsewhere, probably here).

Oops, this line got lost in cut-and-paste:

In feed, feedburner:browserFriendly - child text is text (no HTML)

Feel free to hit me with your usual brand of picky questions, and I’ll try to answer them.

A common misunderstanding.  <source> is only allowed to point to a feed, not an HTML page.

True, and I remembered that about 10 minutes after posting.  That’s what I get for dashing off a comment without fact-checking first. 

Agreed, but the reality is that people are pointing to HTML pages from source elements (NewsGator link blogs being one example).

Interesting.  Sure enough, it’s there.  I wonder why?  Considering the clipping feed seems to contain the original <link> and <guid> (if present), that seems totally out of whack.

Feel free to hit me with your usual brand of picky questions, and I’ll try to answer them.

• integer (emailServiceId): nonnegative?  positive?
• URI (various): relative?  absolute?
• text (feedFlare): plain?  html?
• attributes (xmlView, feedFlare): optional?  required?

All attributes I listed are required.  All text is plain unless you can find a counterexample.  Checking on the rest.

initial test suite — only deployed on beta.feedvalidator.org at this time.

Feel free to try various feeds and report back any issues here.

initial test suite — only deployed on beta.feedvalidator.org at this time.

At the moment, beta.feedvalidator.org is returning “An error occurred while trying to validate this feed” on every feed I’ve given it (including the feeds in your test suite).

but only feeds that include dates.  :-)

I started to take a look at comparing dates for “future” in terms of minutes instead of hours, and looked into time zone handling, made use of python libraries for rfc822 and iso8601 that were only available on python2.4 and python2.5 respectively...

I’ve switched beta.feedvalidator.org to python2.5 temporarily while I figure out this mess.

Thanks for digging into that, Mark. I’m actually on leave for a couple of weeks because of the birth of my son last Friday, but I’ll check around when I get a chance and confirm that it’s an exhaustive list for the existing FeedBurner codebase.

(Again speaking as a Google employee)  A few updates on my previous comments:

• All URIs must be absolute.
• Leading and trailing whitespace is not significant in anything except browserFriendly, where it can be collapsed.
• All text values must be treated as plain text, not escaped HTML.  browserFriendly value may contain escaped HTML, but it’s displayed as-is, not rendered as HTML.  feedFlare value may not contain escaped HTML at all.
• emailServiceId is a positive integer.  Lower limit is 1.  There is no upper limit.
• xmlView is never published.  (It’s used internally in an intermediate step for something or other, but it never makes it into any published feed.)  So treat its presence as an error.
• Ditto origFeed.
• Ditto formattedDate.
• Ditto source.
• That leaves feedFlare as the only element with attributes.  Both attributes are required in each feedFlare element.
• feedFlare elements may occur more than once.  Each feedFlare must have a unique (within the feed) href attribute, after trimming leading and trailing whitespace.  Use a byte-by-byte comparison function.
• Not sure about the cardinality of origLink and origEnclosureLink.
• All other elements may occur 0 or 1 times.

I think that covers it.  Official documentation coming soon, after some internal review.  Just wanted to give you a heads up so you could update your test cases.

Official FeedBurner Namespace Reference.

This thread is the best place to submit feedback.

Deployed.

feedburner:feedFlare/@href isn’t necessary to be an absolute URL, an use case here:

[link]

Actually, I think it is not worth validating a vendor extension which is used privately. The Feed Validator may just recognize the namespace and mark that as safe without any validation.

feedburner:feedFlare/@href isn’t necessary to be an absolute URL

I’ll assume that that is feedback to the spec writers.  Defining how to use of relative URIs in the context of feed formats such as RSS 1.0 (your example) will be... interesting.  But if the specs are updated, the validator will follow.

Actually, I think it is not worth validating a vendor extension which is used privately. The Feed Validator may just recognize the namespace and mark that as safe without any validation.

The problem is that this goes beyond ‘private use’.  In fact, any feed to which the public feedvalidator.org site has access to is, by definition, a public feed.

Um... Even though the feed goes public, no feed reader is expected or officially permitted to use them. In this case, would you explain why the FeedValidator has to validate the FeedBurner namespace?

I agree with Franklin, although he doesn’t makes the case very well – feed readers are well within their rights to use this information, if their authors so choose.

But more to the point, no one but FeedBurner is generating those extension elements, and since the FeedBurner code is the authoritative spec, their use of their extension is by definition correct. So validating these extension elements in detail seems to confer no benefit to anyone and appears rather like… an academic exercise, to stay clear of the more prurient synonym.

no one but FeedBurner is generating those extension elements

Prove it.

(Speaking as a Google employee)

Feedback acknowledged.  The feedFlare @href and @src attributes may be relative URIs.  Official docs will be updated after internal review. 

Google takes no position on how to resolve relative URIs within our extension elements.  Our docs will simply state: “Consult the specification for the surrounding feed format to determine how to resolve relative URIs.”  The feed validator may issue whatever warnings you deem appropriate if a relative URI is present within a feed whose specification does not give sufficient guidance for resolving relative URIs.

<blockquote>no one but FeedBurner is generating those extension elements

Prove it.

</blockquote>

That is extremely difficult to be proven... However, I do wonder if anybody will use the elements under the FeedBurner namespace without burning his/her feeds with FeedBurner.

On the other hand, the FeedValidator isn’t validating the XHTML and SVG namespaces. It accepts all elements no matter if they are known, no undefined element warning is issued.

the FeedValidator isn’t validating the XHTML and SVG namespaces

Fixed.  Thanks!

Jacques: can you do me a favor and review this page for completeness?

Jacques: can you do me a favor and review this page for completeness?

A quick look, comparing with HTML5lib, yields the following:

• Missing from the Wiki, which should be there:

    — MathML elements: annotation, annotation-xml, semantics

• On the Wiki, which shouldn’t be there:

    —SVG Element: image

• On the Wiki, which should (?) be in HTML5lib:

    — HTML Element: wbr
    — URI Schemes: tel, wtai

The Wiki also supports some Data-URIs (which I’m not too keen about). And it doesn’t suport restrictions on SVG attributes which are URIs (see the SVG_ATTR_VAL_ALLOWS_REF and SVG_ALLOW_LOCAL_HREF arrays in HTML5lib).

(P.S.: Note the stunningly unsemantic lengths I went to, to produce a nested list.)

I probably should have mentioned

• the reason why I asked


• it can be found here


• note the nested lists.


• produced by intending the asterisks

Ian Hickson: <wbr> isn’t valid HTML (and never has been)

I tried

• Indented asterisks.


• Evidently, I didn’t indent them *enough*.

<wbr> isn’t valid HTML (and never has been)

Ah. Well, that explains why I’ve never heard of it. That leaves a couple of URI schemes I’ve never heard of either.

in entry, feedburner:origLink - child text is URI

Is it meant to be origLink or origlink?

This thread is the best place to submit feedback

emailServiceId no longer is an integer?  example

Updated emailServiceId documentation.

Fix deployed.

This thread is the best place to submit feedback

channel contains more than one feedburner:emailServiceId

Did feedburner change again?