Loading ...
Sorry, an error occurred while loading the content.

Re: Whose day should I skip?

Expand Messages
  • Randy Morin
    This is likely an area where we can clear up the spec. We have several options, of which two are... -Specify the handling of these elements more precisely.
    Message 1 of 16 , Feb 1, 2006
    View Source
    • 0 Attachment
      This is likely an area where we can clear up the spec. We have
      several options, of which two are...
      -Specify the handling of these elements more precisely.
      -Accept that it's unused by both publishers and aggregators and
      deprecate it.

      Randy Charles Morin

      --- In rss-public@yahoogroups.com, "rcade" <rcade@y...> wrote:
      >
      > Going all the way back to Netscape 0.91, I can't find a spec that
      > indicates the timezone to use for <day>. Because skipDays and
      > skipHours have been documented together in all revisions of
      2.0.1 ...
      >
      > http://www.rssboard.org/skip-hours-days
      >
      > ... I probably would have implemented day using GMT because hour
      > specifies it. Does anyone know of aggregators that support
      skipDays?
      > I'll ask their developers what they did (and why).
      >
      > As we work on this, I'll post an outline of unanswered questions
      that
      > are still being evaluated. Thanks for the quick feedback!
      >
    • Sam Ruby
      ... First, kudos for being willing to at least vocalize the tough decisions that need to be made. Proposal: a change is made to the Feed Validator to flag the
      Message 2 of 16 , Feb 1, 2006
      View Source
      • 0 Attachment
        Randy Morin wrote:
        > This is likely an area where we can clear up the spec. We have
        > several options, of which two are...
        > -Specify the handling of these elements more precisely.
        > -Accept that it's unused by both publishers and aggregators and
        > deprecate it.

        First, kudos for being willing to at least vocalize the tough decisions
        that need to be made.

        Proposal: a change is made to the Feed Validator to flag the use of this
        item with a warning and a link to an extended [help] page. The extended
        help page describes the time zone issue and suggests that anybody who
        has any known use cases or can make suggestions as to spec text do so on
        this (rss-public@yahoogroups.com) list.

        You can even provide the wording for this.

        If no use cases and/or acceptable suggestions are made to this list in
        some period of time (say, 90 days), the element is marked deprecated in
        the next revision of the spec.

        - Sam Ruby
      • Randy Morin
        Sam, Do you already have extended help pages in the FeedValidator for ? If so, then would you mind sharing how many pageviews you get? Thanks, Randy
        Message 3 of 16 , Feb 1, 2006
        View Source
        • 0 Attachment
          Sam,
          Do you already have extended help pages in the FeedValidator for
          <skipX>? If so, then would you mind sharing how many pageviews you
          get?
          Thanks,

          Randy Charles Morin

          --- In rss-public@yahoogroups.com, Sam Ruby <rubys@i...> wrote:
          >
          > Randy Morin wrote:
          > > This is likely an area where we can clear up the spec. We have
          > > several options, of which two are...
          > > -Specify the handling of these elements more precisely.
          > > -Accept that it's unused by both publishers and aggregators and
          > > deprecate it.
          >
          > First, kudos for being willing to at least vocalize the tough
          decisions
          > that need to be made.
          >
          > Proposal: a change is made to the Feed Validator to flag the use
          of this
          > item with a warning and a link to an extended [help] page. The
          extended
          > help page describes the time zone issue and suggests that anybody
          who
          > has any known use cases or can make suggestions as to spec text do
          so on
          > this (rss-public@yahoogroups.com) list.
          >
          > You can even provide the wording for this.
          >
          > If no use cases and/or acceptable suggestions are made to this
          list in
          > some period of time (say, 90 days), the element is marked
          deprecated in
          > the next revision of the spec.
          >
          > - Sam Ruby
          >
        • Sam Ruby
          ... The Feed Validator only has extended help pages for conditions that involve warnings or errors. Three such messages are specific to SkipHours and/or
          Message 4 of 16 , Feb 1, 2006
          View Source
          • 0 Attachment
            Randy Morin wrote:
            > Sam,
            > Do you already have extended help pages in the FeedValidator for
            > <skipX>? If so, then would you mind sharing how many pageviews you
            > get?

            The Feed Validator only has extended help pages for conditions that
            involve warnings or errors. Three such messages are specific to
            SkipHours and/or SkipDays:

            http://feedvalidator.org/docs/error/EightDaysAWeek.html
            http://feedvalidator.org/docs/error/InvalidHour.html
            http://feedvalidator.org/docs/error/NotEnoughHoursInTheDay.html

            I keep apache logs around for 7 days. In the past seven days here is the
            traffic for these pages:

            EightDaysAWeek was visited 165 times, 0 times with a referer that
            includes the string "check".

            InvalidHour was visited 170 times, 0 times with a referer that includes
            the string "check".

            NotEnoughHoursInTheDay was visited 79 times, 0 times with a referer that
            includes the string "check".

            Conclusion: these errors are not common, and the visitors are likely all
            bots. Or, starting now, people who follow links from this email. ;-)

            - Sam Ruby
          • philringnalda
            ... I suspect that IE7b2-preview/Windows RSS Platform/Microsoft Feeds API does, since it s one of the things the API exposes[1] without making you dig it out
            Message 5 of 16 , Feb 6, 2006
            View Source
            • 0 Attachment
              --- In rss-public@yahoogroups.com, "rcade" <rcade@...> wrote:
              > Does anyone know of aggregators that support skipDays?
              > I'll ask their developers what they did (and why).

              I suspect that IE7b2-preview/Windows RSS Platform/Microsoft Feeds API
              does, since it's one of the things the API exposes[1] without making
              you dig it out of the XML, but I haven't worked out a testcase for
              exactly how they support it yet.

              Phil Ringnalda

              [1]
              http://msdn.microsoft.com/library/default.asp?url=/library/en-us/feedsapi/rss/reference/properties/skipdays.asp
            • Phil Ringnalda
              ... Since it merrily fetched my testcase [1] past 00:00 Tuesday GMT, and through 05:00 GMT and 06:00 GMT, and past 00:00 Tuesday PST, and through 05:00 PST and
              Message 6 of 16 , Feb 7, 2006
              View Source
              • 0 Attachment
                I wrote:
                > --- In rss-public@yahoogroups.com, "rcade" <rcade@...> wrote:
                >> Does anyone know of aggregators that support skipDays?
                >> I'll ask their developers what they did (and why).
                >
                > I suspect that IE7b2-preview/Windows RSS Platform/Microsoft Feeds API
                > does, since it's one of the things the API exposes[1] without making
                > you dig it out of the XML, but I haven't worked out a testcase for
                > exactly how they support it yet.

                Since it merrily fetched my testcase [1] past 00:00 Tuesday GMT, and
                through 05:00 GMT and 06:00 GMT, and past 00:00 Tuesday PST, and through
                05:00 PST and 06:00 PST, I guess it doesn't actually implement either
                one, rightly or wrongly. I hope that means they just haven't implemented
                it *yet*, since having a feed fetching library that implements an API to
                tell consumers the times when it wouldn't fetch feeds, except that it
                will anyway, would be pretty twisted.

                Phil Ringnalda

                [1] http://dev.philringnalda.com/rsstests/skipdays.xml
              • ecomputerd
                Strictly following skipDays and skipHours can make it difficult to get the latest update, if 1) the update happened to occur between the last client pull and
                Message 7 of 16 , Feb 7, 2006
                View Source
                • 0 Attachment
                  Strictly following skipDays and skipHours can make it difficult to
                  get the latest update, if 1) the update happened to occur between
                  the last client "pull" and the beginning of a skipDay and 2) the
                  client is directed to pull the feed on a skipDay.

                  After looking at a few pages of specifications for the skipDays and
                  skipHours definitions, I still think that either 1) there is
                  confusion about skipDays and skipHours, or 2) skipDays and skipHours
                  are not completely useless but definately misleading for
                  mobile "semi-connected" devices.

                  Most people's interpretation would likely be "skipDays and skipHours
                  specify when the client will not fetch the feed." This is the
                  specification here: http://blogs.law.harvard.edu/tech/skipHoursDays

                  Some other interpretations are:

                  http://www.shas3.com/rss,0.91,specification.html
                  <day>Day on which the channel will not be updated (e.g. Saturday)
                  </day>
                  <hour>GMT Hour, during which the channel will not be updated (e.g. 7
                  or 19)</hour>

                  http://www.petefreitag.com/item/465.cfm
                  "Yes the TTL feature is very handy, I omitted it from this example
                  because I didn't want to overload people with details. Also handy is
                  the skipDays, skipHours tags, if your a business and you only update
                  the content on weekdays you can tell readers to take the weekend
                  off."

                  These second interpretations are subtley different from the first
                  one, and actually are more useful. See my previous post here:
                  http://groups.yahoo.com/group/rss-public/message/65

                  Bottom line for me is that skipDays and skipHours are misleading for
                  devices that are not connected to the web all the time. I'd much
                  rather have an element that tells me when the scheduled updates are
                  going to be. But maybe that's covered with the TTL element.


                  Anyone care to enlighten me?

                  Seeing how the skipDays are skipHours elements variously interpreted
                  or ignored depending on the aggregator, I'd probably implement
                  skipDays and skipHours according to interpretation 2. Is there any
                  danger if I did this?

                  Greg Smith
                  Author, FeederReader - Pocket PC *direct* RSS text, audio, video,
                  podcasts
                  www.FeederReader.com - Download on the Road
                • rcade
                  ... This is true. One of the things to weigh in implementing skipDays and skipHours is how rigidly to follow them. The only potential next-update-time
                  Message 8 of 16 , Feb 7, 2006
                  View Source
                  • 0 Attachment
                    --- In rss-public@yahoogroups.com, "ecomputerd" <ecomputerd@...> wrote:
                    > Strictly following skipDays and skipHours can make it difficult to
                    > get the latest update, if 1) the update happened to occur between
                    > the last client "pull" and the beginning of a skipDay and 2) the
                    > client is directed to pull the feed on a skipDay.

                    This is true. One of the things to weigh in implementing skipDays and
                    skipHours is how rigidly to follow them.

                    The only potential "next-update-time" mechanism in RSS I can think of
                    would be to set ttl to the number of minutes 'til that time. A feed 10
                    hours from the next expected update could have <ttl>600</ttl>, then
                    when it's 2 hours it could be <ttl>120</ttl>.

                    However, there are bandwidth implications whenever you change the
                    value of a channel element when none of the document's items have
                    changed. Aggregators that are good HTTP citizens will have to request
                    the entire document again just because of the changed ttl. (I did this
                    once in a default Movable Type template, setting the pubDate to the
                    current time instead of the time of the most recent weblog entry, and
                    it nearly killed Mark Pilgrim.)

                    For this reason, I'd look to namespaces for this desired
                    functionality, at least in Really Simple Syndication 2.0.
                  • ecomputerd
                    I m not sure if I d look to namespaces for this desired functionality means If I were ecomputerd, I would start looking... or if rcade was interested, he
                    Message 9 of 16 , Feb 7, 2006
                    View Source
                    • 0 Attachment
                      I'm not sure if "I'd look to namespaces for this desired
                      functionality" means "If I were ecomputerd, I would start
                      looking..." or "if rcade was interested, he would look...". In
                      either case, it's very unlikely that if it's not in the spec, it's
                      unlikely to be implemented widely.

                      My main point was that it's ambiguous at best and misleading at
                      worst. The exact thing I thought a "specification" was supposed to
                      clarify.

                      I'm not trying to be flippant or rude. I'm simply pointing out a
                      perfect case where a specification can do some good regarding
                      clarification, especially given that there are already multiple
                      interpretations out there. Oh, and a few links I didn't find in time
                      to send in the last message:

                      (RSS 0.91)
                      http://www.rssboard.org/rss-0-9-1-netscape#skipDays

                      "indicating the days of the week when your channel will not be
                      updated"

                      consistent (and exact wording of):
                      (RSS 0.91)
                      http://my.netscape.com/publish/formats/rss-spec-0.91.html#skipDays

                      "indicating the days of the week when your channel will not be
                      updated"

                      (RSS 0.92)
                      http://www.shas3.com/rss,0.92,specification.html
                      "Day on which the channel will not be updated"

                      An exact reversal of

                      (RSS 2.0)
                      http://blogs.law.harvard.edu/tech/skipHoursDays

                      "Aggregators may not read the channel during days listed in the
                      skipDays element."

                      (RSS 2.0)
                      http://www.kbcafe.com/rss/rssfeedstate.html#skiphoursandskipdays

                      "By adding these elements to our RSS feeds, we're telling RSS
                      readers to stop polling during these hours or even days."

                      And this chart: http://64.233.179.104/search?
                      q=cache:GSGTCjgY9tIJ:www.pablotron.org/files/rss_elements-
                      20041014.xls+rss+0.91+skipDays&hl=en&gl=us&ct=clnk&cd=50

                      seems to indicate that (presumably because the name is the same in
                      0.91/0.92/2.0) the three specs treat skipDays/Hours the same way:
                      "Aggregators may not read the channel during hours listed in the
                      skipDays element. (Most aggregators seem to ignore this element.)"

                      So by keeping the element, suggesting that it is indeed up to
                      interpretation, in fact encouraging an aggregator developer to
                      decide for himself how to interpret it, and not clarifying its
                      meaning in the specification seems an utterly egregious thing to do.

                      Again, I'm not trying to be flippant or rude, just calling it like I
                      see it. If the use isn't clarified in the specification, it will
                      continue to be useless element baggage.

                      Regarding use of TTL changing the file and "forcing" aggregators to
                      download multiple times even if TTL is the only changing element is
                      the exact reason for an element that specifies the absolute update
                      times, even though the re-feeding could be managed by a server-side
                      script and appropriate recognition and processing of ETag/If-None-
                      Match or Last-Modified/If-Modified-Since headers, but this requires
                      a cgi-script rather than just placing a static file.

                      Just thoughts. Comments?

                      Greg Smith
                      Author, FeederReader - Pocket PC *direct* RSS text, audio, video,
                      podcasts
                      www.FeederReader.com - Download on the Road



                      --- In rss-public@yahoogroups.com, "rcade" <rcade@...> wrote:
                      >
                      > --- In rss-public@yahoogroups.com, "ecomputerd" <ecomputerd@>
                      wrote:
                      > > Strictly following skipDays and skipHours can make it difficult
                      to
                      > > get the latest update, if 1) the update happened to occur
                      between
                      > > the last client "pull" and the beginning of a skipDay and 2) the
                      > > client is directed to pull the feed on a skipDay.
                      >
                      > This is true. One of the things to weigh in implementing skipDays
                      and
                      > skipHours is how rigidly to follow them.
                      >
                      > The only potential "next-update-time" mechanism in RSS I can think
                      of
                      > would be to set ttl to the number of minutes 'til that time. A
                      feed 10
                      > hours from the next expected update could have <ttl>600</ttl>, then
                      > when it's 2 hours it could be <ttl>120</ttl>.
                      >
                      > However, there are bandwidth implications whenever you change the
                      > value of a channel element when none of the document's items have
                      > changed. Aggregators that are good HTTP citizens will have to
                      request
                      > the entire document again just because of the changed ttl. (I did
                      this
                      > once in a default Movable Type template, setting the pubDate to the
                      > current time instead of the time of the most recent weblog entry,
                      and
                      > it nearly killed Mark Pilgrim.)
                      >
                      > For this reason, I'd look to namespaces for this desired
                      > functionality, at least in Really Simple Syndication 2.0.
                      >
                    • rcade
                      ... Are you referring to existing specs or the proposed spec? In the proposal, the use of SHOULD NOT in the skipDays and skipHours sections has specific
                      Message 10 of 16 , Feb 7, 2006
                      View Source
                      • 0 Attachment
                        --- In rss-public@yahoogroups.com, "ecomputerd" <ecomputerd@...> wrote:
                        > My main point was that it's ambiguous at best and misleading at
                        > worst. The exact thing I thought a "specification" was supposed to
                        > clarify.

                        Are you referring to existing specs or the proposed spec?

                        In the proposal, the use of SHOULD NOT in the skipDays and skipHours
                        sections has specific meaning, as defined in RFC 2119:

                        "4. SHOULD NOT This phrase, or the phrase 'NOT RECOMMENDED' mean
                        that there may exist valid reasons in particular circumstances when
                        the particular behavior is acceptable or even useful, but the full
                        implications should be understood and the case carefully weighed
                        before implementing any behavior described with this label."

                        An aggregator SHOULD NOT request a channel during a skip day or skip
                        hour, which means there's room for judgment.

                        http://www.rssboard.org/rss-draft-1#element-channel-skipdays

                        > Again, I'm not trying to be flippant or rude, just calling it like I
                        > see it. If the use isn't clarified in the specification, it will
                        > continue to be useless element baggage.

                        I understand, but I'm not sure what you think needs to be clarified.
                        When you say that skipDays causes problems for a mobile aggregator
                        because of the Thursday/Saturday scenario, aren't you arguing in favor
                        of "SHOULD NOT" over "MUST NOT"?
                      • ecomputerd
                        Thank you for your response. The clarification I was seeking goes beyond SHOULD NOT or MUST NOT . Instead of: stipulates the days of the week that the
                        Message 11 of 16 , Feb 7, 2006
                        View Source
                        • 0 Attachment
                          Thank you for your response. The clarification I was seeking goes
                          beyond "SHOULD NOT" or "MUST NOT".

                          Instead of:
                          "stipulates the days of the week that the channel SHOULD NOT be
                          requested by an aggregator"

                          I suggest:
                          "stipulates the days of the week during which the channel is not
                          updated. It is intended that an aggregator SHOULD request the feed
                          no more than once during a period of consecutive skipDays."

                          And similarly for skipHours.

                          I believe this is a more useful explanation of (what I think is) the
                          intention. Even so, if this is the actual intention, there is surely
                          a much better way of specifying this (like an unlimited number of
                          skipRanges which specify begin/end time and date pairs. Or UNIX-
                          style cron specification, for example.

                          As an alternative (or addition--this might not belong in this
                          message), I'd like to see an element with the intention of "updates
                          occur every Friday at 8am". Very appropriate for a news feed or any
                          other very-regularly-added-to feeds.

                          Greg Smith
                          Author, FeederReader - The Pocket PC RSS Aggregator

                          --- In rss-public@yahoogroups.com, "rcade" <rcade@...> wrote:
                          >
                          > --- In rss-public@yahoogroups.com, "ecomputerd" <ecomputerd@>
                          wrote:
                          > > My main point was that it's ambiguous at best and misleading at
                          > > worst. The exact thing I thought a "specification" was supposed
                          to
                          > > clarify.
                          >
                          > Are you referring to existing specs or the proposed spec?
                          >
                          > In the proposal, the use of SHOULD NOT in the skipDays and
                          skipHours
                          > sections has specific meaning, as defined in RFC 2119:
                          >
                          > "4. SHOULD NOT This phrase, or the phrase 'NOT RECOMMENDED' mean
                          > that there may exist valid reasons in particular circumstances when
                          > the particular behavior is acceptable or even useful, but the full
                          > implications should be understood and the case carefully weighed
                          > before implementing any behavior described with this label."
                          >
                          > An aggregator SHOULD NOT request a channel during a skip day or
                          skip
                          > hour, which means there's room for judgment.
                          >
                          > http://www.rssboard.org/rss-draft-1#element-channel-skipdays
                          >
                          > > Again, I'm not trying to be flippant or rude, just calling it
                          like I
                          > > see it. If the use isn't clarified in the specification, it will
                          > > continue to be useless element baggage.
                          >
                          > I understand, but I'm not sure what you think needs to be
                          clarified.
                          > When you say that skipDays causes problems for a mobile aggregator
                          > because of the Thursday/Saturday scenario, aren't you arguing in
                          favor
                          > of "SHOULD NOT" over "MUST NOT"?
                          >
                        • rcade
                          ... Thanks. Describing it as a declaration by a publisher makes sense. I ll tackle it in the next draft.
                          Message 12 of 16 , Feb 8, 2006
                          View Source
                          • 0 Attachment
                            --- In rss-public@yahoogroups.com, "ecomputerd" <ecomputerd@...> wrote:
                            > I suggest:
                            > "stipulates the days of the week during which the channel is not
                            > updated. It is intended that an aggregator SHOULD request the feed
                            > no more than once during a period of consecutive skipDays."

                            Thanks. Describing it as a declaration by a publisher makes sense.
                            I'll tackle it in the next draft.
                          Your message has been successfully submitted and would be delivered to recipients shortly.