On 04/07/2005, at 6:18 PM, Thomas Broyer wrote:
Really good work!

Thanks!


Why not using an xs:boolean for fh:stateful? hence allowing values 0, 1, true and false.

I did it this way because I'm not a huge XML Schema fan :)

At this point, stateful is effectively xs:boolean with a constraint on the lexical space. I'm not against changing it to '"1" or "true" / "0" or "false", except that this makes the spec more verbose (but that's a pretty minor concern, properly managed). What do others think (in either direction)?


With the -01 draft (it might have been the same within the -00 one too), one can't reuse the process to link to archives of "Top Twenty Records" or "Most Popular Items" (e.g. a monthly "Top Twenty Records" linking to the previous-month "Top"), because of the "a subscription document whose fh:stateful element contains "false" MUST NOT contain a fh:prev element".
Why not just stating that if fh:stateful is false then the "prev"-linked archive feed doesn't not contain a subset of the previous entries but rather does contain the previous state of the subscription feed. I.e. the meaning of the fh:prev "link" depends on the value of fh:stateful.

That's interesting, but it somewhat changes the semantics of "prev"; it goes from "where you can find previous entries in a logical feed" to "where you can find an older archive of entries." While these are often the same thing, it might not always be the case; i.e., someone might want to publish a non-time-based feed. 

So, I'm nervous about having two different semantics for one element, depending upon its context of use. 


Also, shouldn't there be a note to invite producers to provide an atom:[EMAIL PROTECTED]"self" referencing the subscription feed?

Agreed. Ideally, Atom would have separate concepts of 'syndication' and 'archive' feeds, and make this recommendation itself. As it is, the semantic of 'self' in an archive feed is a bit fuzzy. 


I also repeat my proposal for an identifier different from an URI for a reader/aggregator to know whether it has already retrieved an archive document, e.g. using the "updated" date-time of the "fh:prev"-linked archive feed.

Example:
  <?xml version="1.0" encoding="utf-8"?>
    xmlns:history="[TBD]">
    <title>Example Feed</title>
    <link href=""http://example.org">http://example.org/"/>
    <updated>2003-12-13T18:30:02Z</updated>
    <author>
      <name>John Doe</name>
    </author>
    <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
    <history:stateful>true</history:stateful>
<!--
added an "updated" attribute with tha atom:updated value
-->
    <history:prev updated="2003-11-24T12:00:00Z">

    <entry>
      <title>Atom-Powered Robots Run Amok</title>
      <link href=""http://example.org/2003/12/13/robots_here">http://example.org/2003/12/13/robots_here"/>
      <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
      <updated>2003-12-13T18:30:02Z</updated>
      <summary>Some text in a new, fresh entry.</summary>
    </entry>

  </feed>

If I retrieved the feed between 2003-11-24T12:00:00Z and 2003-12-13T18:30:02Z, the fh:prev URI were probably equal to http://example.org/2003/10/index.atom (october, not november). However, I didn't miss any entry.
Using the fh:[EMAIL PROTECTED] value, I can know that I didn't miss any entry and that I then don't need to dereference http://example.org/2003/11/index.atom (november, the "new" fh:prev URI)

Hmm, that seems awfully complex (and hard to grasp -- but maybe it's just me :) just to avoid a round trip. That 'probably' is also worrying me. How would you express this in the 'reconstructing state' section? 

Cheers,

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

Reply via email to