Subject: atom 0.3 feed with link rel="related" considered valid by feedvalidator

From: patrick chanezon <[email-masked]>
Date: Fri, 25 Feb 2005 12:04:03 +0100

http://feedvalidator.org/check.cgi?url=http://kebernet.blogspot.com/atom.xml
marks http://kebernet.blogspot.com/atom.xml as valid

It uses a link rel="related" where this value is clearly invalid 
according to 
http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.3.4.1
and http://bitworking.org/projects/atom/draft-gregorio-09.html

This attribute value is valid in the atom 0.5 spec.
But the feed header identifies it as

<feed version="0.3" xml:lang="en-US" xmlns="http://purl.org/atom/ns#">

instead of

<feed version="draft-ietf-atompub-format-05:do not deploy"
   xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-

as the atom 0.5 spec mandates.

see https://rome.dev.java.net/servlets/ReadMsg?list=users&msgNo=197 for 
details.

I've looked at a few blogger generated feeds and they don't have this 
element, and there is no way in blogger to change the atom generation 
template, so I guess Google must have picked up a few random blogs to 
test out a new Atom 0.5 template where they generate this <link 
rel="related" .../> element based on a link analysis of the post content.
This is a good move but I wish they'd use the spec's proper version 
String... even if the string's english semantics contradicts its use in 
deployment:-)

The blogger developer blog http://www.blogger.com/developers/ mentioned 
using atom-syntax for feedback about their atom support, so I CC this 
list as well.

In ROME <https://rome.dev.java.net/> I suggested that we relax the 
contsraint we put on the rel attribute in order to allow for Atom 0.5 
syntax even if the version is wrongly specified.
I wanted to get your opinion about this, and maybe some rationale about 
why you chose this approach in FeedValidator, which is supposed to 
adhere more strictly to the specs than our parsing library.

P@

---

From: Eric Scheid <[email-masked]>
Date: Fri, 25 Feb 2005 23:29:24 +1100

On 25/2/05 10:04 PM, "patrick chanezon" <[email-masked]> wrote:

> It uses a link rel="related" where this value is clearly invalid according to
> http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.3.
> 4.1 and http://bitworking.org/projects/atom/draft-gregorio-09.html
> 
not so clearly invalid. nottingham-02 defers to gregorio-09, which describes
the values of @rel as "a space-separated list of link types", but doesn't
defined what "link types" is. It is then followed by spec text which
describes how to interpret certain link types if the @type has a specific
value. It doesn't say that those link types are the only valid link types.

> This attribute value is valid in the atom 0.5 spec. But the feed header
> identifies it as <feed version="0.3" xml:lang="en-US"
> xmlns="http://purl.org/atom/ns#" <http://purl.org/atom/ns#> > instead of <feed
> version="draft-ietf-atompub-format-05:do not deploy"
> xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format- as the atom 0.5 spec
> mandates.
> 

There is no "atom 0.5 spec". There is a 6th IETF spec though, which is what
you are referencing above. There was also a 5th ("04"), 4th ("03"), 3rd
("02"), 2nd ("01"), and a 1st IETF spec ("00"), which followed the 0.3
nottingham spec. Confused yet?

> I've looked at a few blogger generated feeds and they don't have this element,
> and there is no way in blogger to change the atom generation template, so I
> guess Google must have picked up a few random blogs to test out a new Atom 0.5
> template where they generate this <link rel="related" .../> element based on a
> link analysis of the post content.
> 
> This is a good move but I wish they'd use the spec's proper version String...
> even if the string's english semantics contradicts its use in deployment:-)
> 
The blogger.com atom feed is a 0.3 feed. You can tell because there is no
<head> element, and there are <issued>, <modified>, and <created> elements.

> The blogger developer blog http://www.blogger.com/developers/ mentioned using
> atom-syntax for feedback about their atom support, so I CC this list as well.
> 
> In ROME <https://rome.dev.java.net/>  I suggested that we relax the contsraint
> we put on the rel attribute in order to allow for Atom 0.5 syntax even if the
> version is wrongly specified.
> 
> I wanted to get your opinion about this, and maybe some rationale about why
> you chose this approach in FeedValidator, which is supposed to adhere more
> strictly to the specs than our parsing library.

e.

---

From: Sam Ruby <[email-masked]>
Date: Fri, 25 Feb 2005 07:27:39 -0500

> adhere more strictly to the specs than our parsing library.

First, a statement of direction.  At or shortly after Atom 1.0 goes 
final, the feedvalidator will no longer consider Atom 0.3 feeds as valid.

As to pre-IETF history, the development was quite a bit less formal and 
rigorous, and therefore a number of factors were considered in the Atom 
0.3 support.  In particular, the following two sources were also taken 
as input:

http://intertwingly.net/wiki/pie/LinkTagMeaning
http://www.xml.com/lpt/a/2004/06/16/dive.html

- Sam Ruby

---

From: patrick chanezon <[email-masked]>
Date: Fri, 25 Feb 2005 13:50:37 +0100

>  and MUST be one of the values enumerated in the Atom API 
> specification 
> <eref>http://bitworking.org/projects/atom/draft-gregorio-09.html</eref>.

I can see only one enumeration of values in gregorio-09, and 7 values 
enumerated in it. And MUST in the initial spec.

But I think you're right: the spirit of the spec seems to be to let you 
specify anything in there, so if there is no objections, we'll just 
gladly change our parser and close the issue.
The wording is just ambiguous (why talk about enumeration when you 
provide a description and an enumeration just for a specific case?)

I CC the rome users list to have an archive of the rationale for that 
change.

Sorry for the mixup in spec names: I did not know IETF used a 
C-array-indexing like semantics for its specs:-)

P@

---

From: patrick chanezon <[email-masked]>
Date: Fri, 25 Feb 2005 21:39:15 +0100

Thanks Sam,
we'll remove the check we currently have in ROME for rel values then.

P@

Sam Ruby wrote:

>
> patrick chanezon wrote:
>
>> I wanted to get your opinion about this, and maybe some rationale 
>> about why you chose this approach in FeedValidator, which is supposed 
>> to adhere more strictly to the specs than our parsing library.
>
>
> As to pre-IETF history, the development was quite a bit less formal 
> and rigorous, and therefore a number of factors were considered in the 
> Atom 0.3 support.  In particular, the following two sources were also 
> taken as input:
>