Re: [FeedValidator] atom 0.3 feed with link rel="related" considered valid by feedvalidator

[patrick chanezon]

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.

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

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

[patrick chanezon]

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

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@

Eric Scheid wrote:

  On 25/2/05 10:04 PM, "patrick chanezon" <[EMAIL PROTECTED]> 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 "http://purl.org/atom/ns#"  > instead of 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?

  
  
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  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
 element, and there are , , and  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   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.

  

Re: [FeedValidator] atom 0.3 feed with link rel="related" considered valid by feedvalidator

[Sam Ruby]

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.
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

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

[Eric Scheid]

On 25/2/05 10:04 PM, "patrick chanezon" <[EMAIL PROTECTED]> 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  xmlns="http://purl.org/atom/ns#";  > instead of  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?

> 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  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
 element, and there are , , and  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   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.

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

[patrick chanezon]

http://feedvalidator.org/check.cgi?url="">
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 
"http://purl.org/atom/ns#">
instead of 
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  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 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@