Re: Feed History -02

[Mark Nottingham]

So, if I read you correctly, it sounds like you have a method whereby  
a 'top20' feed wouldn't need history:prev to give the kind of history  
that you're thinking of, right?


If that's the case, I'm tempted to just tweak the draft so that  
history:stateful is optional if history:prev is present. I was  
considering dropping stateful altogether, but I think something is  
necessary to explicitly say "don't try to keep a history of my feed."  
My latest use case for this is the RSS feed that Netflix provides to  
let you keep an eye on your queue (sort of like top20, but more  
specialised).


Sound good?


On 29/07/2005, at 6:39 AM, Henry Story wrote:



Below I think I have worked out how one can in fact have a top20  
feed, and
I show how this can be combined without trouble with the  


link...


On 29 Jul 2005, at 13:12, Eric Scheid wrote:



On 29/7/05 7:57 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:



1- The top 20 list: here one wants to move to the previous top   
20 list and
think of them as one thing. The link to the next feed is not  
meant to be
additive. Each feed is to be seen as a whole. I have a little  
trouble still

thinking of  these as feeds, but ...




What happens if the publisher realises they have a typo and need  
to emit an
update to an entry? Would the set of 20 entries (with one entry  
updated) be

seen as a complete replacement set?



Well if it is a typo and this is considered to be an insignificant  
change then
they can change the typo in the feed document and not need to  
change any updated

time stamps.


The way I see it, maybe a better way would be to have a sliding  
window feed
where each entry points to another Atom Feed Document with it's  
own URI, and
it is that second Feed Document which contains the individual  
items (the top

20 list).



This is certainly closer to my intuitions too.  A top 20 something  
is *not* a feed.
Feed entries  are not ordered, and are not  meant to be thought of  
as a closed

collection. At least this is my initial intuition. BUT

I can think of a solution like the following: Let us imagine a top  
20 feed where
the resources being described by the entries are the position in  
the top list. So

we have entries with ids such as

http://TopOfThePops.co.uk/top20/Number1
http://TopOfThePops.co.uk/top20/Number2
http://TopOfThePops.co.uk/top20/Number3
...

Each of these resources describes the songs that is at a certain  
rank in the top of
the pops chart. Each week the song in that rank may change. When a  
change occurs in the

song at a certain rank the top 20 feed with id

http://TopOfThePops.co.uk/top20/Feed

will contain a new entry such as

   
Top of the pops entry number 1
http://TopOfThePops.co.uk/top20/Number1/"/>
http://TopOfThePops.co.uk/top20/Number1
2005-07-05T18:30:00Z
Top of the pops winner for the week starting 5 July  
2005

  

A client that would subscribe to such a feed would automatically  
get updates every
week for each of the top 20 resources. But the feed could be  
structured exactly like

I suggest in 2.

So for a top 2 feed (20 is a bit to long for me)


   My top 2 Software Books
   http://bblfish.net/blog/top2
   http://bblfish.net/blog/top2/ 
Archive-2005-07-18.atom

   ...
   
My Top 1 book
http://bblfish.net/blog/top2/Number1/"/>
http://bblfish.net/blog/top2/Number1
2005-07-25T18:30:00Z
My top 1 book is Service Oriented Computing by Wileysummary>

   
   
My Top 2 book
http://bblfish.net/blog/top2/Number2/"/>
http://bblfish.net/blog/top2/Number2
2005-07-25T18:30:00Z
My second top book is "xml in a Nutshell"
  


The above representation of the http://bblfish.net/blog/top2 feed  
points to the

archive feed http://bblfish.net/blog/top2/Archive-2005-07-18.atom


   My top 2 Software Books
   http://bblfish.net/blog/top2
   ...
   
My Top 1 book
http://bblfish.net/blog/top2/Number1/"/>
http://bblfish.net/blog/top2/Number1
2005-07-18T18:30:00Z
My top 1 book is Java 2D Graphics
   
   
My Top 2 book
http://bblfish.net/blog/top2/Number2/"/>
http://bblfish.net/blog/top2/Number2
2005-07-18T18:30:00Z
My second top book is "xml in a Nutshell"
  


 As you notice only the top1 has changed from the first week but  
not the
second, and yet in both feeds there is an entry for both. A non  
change can
sometimes be an important event. But this is really up to the feed  
creator
to choose how to present his feeds. He could easily have had only  
had the

entry for http://bblfish.net/blog/top2/Number1 in the first feed.

Looking at it this way, there really seems to be no incompatibility  
between
a top 20 feed and the  link. My talk about  
archives not

changing should be more precisely about archives not changing in any
significant way. And this advice could be moved to an implementors  
section
and be encoded in HTTP by simply giving archive pages an infinitely  
long

expiry date.

Re: spec bug: can we fix for draft-11?

[Mark Nottingham]

On 02/08/2005, at 9:15 PM, Tim Bray wrote:

So if the WG really thinks this is a sensible clarification I won't  
scream too much.


It's probably necessary any way, because RFC3470/BCP70 Section 4.16  
encourages specs to give guidelines about white space;


   Implementers might safely assume that they can ignore the white  
space
   in the example above, but white space used for pretty-printing  
can be

   a source of confusion in other situations.  Consider a minor change
   to the  element:

   
 10.1.2.3
   

   where white space is found on both sides of the IP address.  XML
   processors treat the white space surrounding "10.1.2.3" as an
   integral part of the  element.  A failure to recognize this
   behavior can lead to confusion and errors in both design and
   implementation.

   All white space is considered significant in XML instances.  As a
   consequence, it is recommended that protocol designers provide
   specific guidelines to address white space handling within  
protocols

   that use XML.




--
Mark Nottingham http://www.mnot.net/

FYI: An Overview of the Atom 1.0 Syndication Format

[James M Snell]

Published yesterday on developerWorks.

http://www-128.ibm.com/developerworks/xml/library/x-atom10.html

Comments welcome.. I'll publish clarifications/corrections on my 
developerWorks blog.

Re: spec bug: can we fix for draft-11?

[Graham]

On 3 Aug 2005, at 2:04 pm, Sam Ruby wrote:



A note that Atom processors may consider leading and trailing space as
significant in attribute and element values would be enough to alert
people to the interoperability issues.



+1

Graham

Re: spec bug: can we fix for draft-11?

[Sam Ruby]

Tim Bray wrote:
> 
> On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote:
> 
>> One way of saying this would be "Atom Processors MAY ignore leading
>> and trailing whitespace in _." That is, no existing
>> software is buggy, but if you want to be sure your document is
>> processed accurately, you should trim the space yourself.
> 
> Ecch.  Blecch.  Barf.

I think we all feel that way.

> I suppose.

That way too.

> I personally think the framework of specifications is crystal-clear, 
> and per the letter of the law
> 
> 
> http://example.com/foo
> 
> 
> is totally illegal because the string \nhttp://example.com/foo\n does 
> not conform to the productions for either URI or IRI.

As Graham noted, the issue is that differing persons approach this with
differing notions of what the term "content" means in this context.

"Document" and "Data" people approach these things with different filters.

To an Infoset person, this following is a completely different stream
from the example above (please ignore any line breaks that your email
client may insert):

http://example.com/foo

Infoset views the below two examples as different:


http://example.com/foo

RelaxNG views all of the above as the same.

> I am less convinced that people are actually going to do this, but I  do
> agree that if a substantial number *do* do this, implementors will 
> simply ignore us and code around it.  So if the WG really thinks this 
> is a sensible clarification I won't scream too much.  -Tim

The reason that one line of code exists in the feedvalidator is because
somebody did do it, existing feed readers supported it, and I couldn't
defend the statement that the RSS 2.0 spec unambiguously prohibited it.

A note that Atom processors may consider leading and trailing space as
significant in attribute and element values would be enough to alert
people to the interoperability issues.

Disallowing leading and trailing whitespace in IRI references (including
the isegment-nz-nc production), MIME media types, language tags,
lengths, addr-spec, and date-time productions would lead to improved
interoperability.

I'm fine with either.

- Sam Ruby

RE: Introduction to The Atom Syndication Format

[Hammond, Tony]

Hi Sam:

This is very a nice summary. Would just query the words:

"If you own your own Internet domain,"

Was my understanding that domain names were leased, not owned. One of the
Internet's dirty little secrets.

Cheers,

Tony


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Danny Ayers
> Sent: 02 August 2005 14:09
> To: Sam Ruby
> Cc: atom-syntax@imc.org
> Subject: Re: Introduction to The Atom Syndication Format
> 
> 
> 
> Looks great.
> 
> My only suggestion would be to expose the MUSTs etc. little 
> more, especially where Atom differees from RSS. E.g. right 
> now it would be easy for someone coming from RSS 2.0 to think 
> that  was the same as .
> 
> So in this case maybe:
> Identifies the feed in a universally unique and permanent 
> way. => Identifies the feed in a universally unique and 
> permanent way, using an IRI. or perhaps Identifies the feed 
> in a universally unique and permanent way, according to rfc3987.
> 
> Cheers,
> Danny.
> 
> 
> -- 
> 
> http://dannyayers.com
> 


   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and 
attachments (if any). No contracts may be concluded on behalf of Macmillan 
Publishers Limited or its agents by means of e-mail communication. Macmillan 
Publishers Limited Registered in England and Wales with registered number 
785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   

Re: spec bug: can we fix for draft-11?

[A. Pagaltzis]

* Tim Bray <[EMAIL PROTECTED]> [2005-08-03 06:30]:
> I personally think the framework of specifications is
> crystal-clear,  and per the letter of the law
> 
> 
> http://example.com/foo
> 
> 
> is totally illegal because the string
> \nhttp://example.com/foo\n does  not conform to the productions
> for either URI or IRI.

That is the way I thought of it also.

> I am less convinced that people are actually going to do this,
> but I do agree that if a substantial number *do* do this,
> implementors will simply ignore us and code around it.  So if
> the WG really thinks this  is a sensible clarification I won't
> scream too much.

I would say the fact that we’ve had a three-day, 40-message
thread about what the spec really says here is sufficient
precedent to conclude that this needs to be explicit. The
ambivalent comment in the relevant section of the RNC grammar is
not helping matters either; that one *must* be fixed, informal or
no.

Regards,
-- 
Aristotle Pagaltzis //