There was discussion in the time leading up to the vote on the 1.0
version of the profile about work for the second edition (which was
referred to as "1.1") — as far as I can see nothing at all has
happened about this (I expect due to time constraints). I'm more than
happy to take over work on co-editing the document (though I wouldn't
be able to do much for a week or so), but I would much rather see some
quite large changes (splitting up publisher/aggregator requirements
into different headers, and expanding the latter in many cases to
cover non-conforming content) — if I am to contribute to it, should I
work from the actual source sent to the browser, or something else?
Finally (and most likely most controversially), I would like to see
all the namespace advice be gone — at most list a few recommended
namespaces, but don't attempt to define them at all.

--
Geoffrey Sneddon
<http://gsnedders.com/>

Mads Hjorth wrote:
> Hi,
>
> I am trying to parse some feeds using the validator on
http://validator.w3.org/feed/
>
> My example does not validate, and I expect an error in the validator.

The validator message in this case is correct as it reflects the
behavior specified by the relevant specifications.

> When I include a date in a lastBuildDate field, with a timezone of CET
> my feed does not validate.
>
>  <lastBuildDate>Wed, 02 Oct 2002 08:00:00 CET</lastBuildDate>  leads
> to  "lastBuildDate must be an RFC-822 date-time"
>
> where as
>
>  <lastBuildDate>Wed, 02 Oct 2002 08:00:00 EST</lastBuildDate>  does
> validate.
>
> I am not sure why Eastern Standard Time is valid and Central European
> Time is not. <deep breath, diving into RFC-822  -> ANSI X3.51-1975 ->
> FIPS 59, deep breath>
>
> It turns out that the only valid identifiers for time zones are UT/GMT
> and EST/CST/MST/PST. <Insert rant about culture biased standards here!>
>
> It seems I am left with +0100 as a time zone for Copenhagen, Denmark.
> In the ansi standard all that is mentioned about this format, is
> "Local differential hours+min. (HHMM)".
>
> Does this mean an offset to GMT?
>
> Don't I loose alot of information about my timezone, by only
> referencing an offset? What about Daylight Saving etc...
>
> What is the best practice for adding date information to feeds
> originating from outside of the few named timezones in the applied
> standards.
>
> Is it way out of hand to recommend an ISO 8601 date instead?

Both RSS 1.0 and the Atom formats use ISO 8601 based dates and times.

Both ISO 8601 and RFC 822 based timestamps support offset from GMT as a
notation.

If you would like to discuss recommendations for RSS 2.0, I would
suggest pursuing that on the RSS Advisory Board mailing list.  The feed
validator already produces a number of recommendations based on their
best practices profile.

> Regards
>
> Mads Hjorth
> External Lecturer, OOP. IT University of Copenhagen.
> www : www.itu.dk/people/madsh
> mail : madsh@...

- Sam Ruby

>> Don't I loose alot of information about my timezone, by only
>> referencing an offset? What about Daylight Saving etc...

You're assuming that information would be something you could reliably
extract from such a thing.  You cannot.  It's a common mistake, to assume
timezone info connotes anything other than time.  It doesn't indicate region
or any other geographic data.  Lots of folks make this assumption, however
incorrect it continues to be.  It'd be nice if geo-data was available, but
the timezone isn't the place to get it.

As for DST calculations, those can't be extracted from this either.  DST
varies FAR MORE than you can possibly imagine.  A good number of programming
tools actually get it wrong when making calculations based on timezone
during a different interval (as in, summer timestamps during a winter tz
offset).

In the end you're far better off using the numeric offsets.  Which are
offsets from UTC, as it's actually possible for GMT itself to be offset due
to daylight savings.  Yes, you will get a big headache learning what a mess
timezones really are...

-Bill Kearney

Mads Hjorth wrote:
> Is it way out of hand to recommend an ISO 8601 date instead?

In an RSS 2.0 feed, yes. The RSS 2.0 spec clearly says that dates should be
in the form described in RFC 822 (with the additional requirement that years
use four digits). If you just choose your own format at random, how would
you expect an RSS reader to understand what you meant?

In short, if you want your dates to be understood, stick to the format as
specified.

If you really find RFC 822 dates that offensive, you could always choose an
entirely different feed format as Sam has suggested. Either way, though,
you're never going to be able to use CET as a timezone.

Bill Kearney wrote:
> In the end you're far better off using the numeric offsets.  Which are
> offsets from UTC, as it's actually possible for GMT itself to be offset
> due
> to daylight savings.

Perhaps I've misunderstood what you're saying, but just to be clear, GMT
never changes as a result of daylight savings. Britain does have a form of
daylight savings (referred to as British Summer Time or BST), but that is
defined as GMT+1 (GMT itself doesn't change).

As I understand it, the difference between UTC and GMT has to do with atomic
time measurement vs. astronomical calculations. For the most part the
differences are insignificant.

Regards
James

It appears that implementing an RSS news reader may be a lot of work to do. At
least when
one reads the web page
http://diveintomark.org/archives/2004/02/04/incompatible-rss

Is the above mentioned web page accurate in its description of incompatibility?

On Sat, Feb 23, 2008 at 1:35 PM, James Holderness <j4_james@...> wrote:
>
>  Perhaps I've misunderstood what you're saying, but just to be clear, GMT
>  never changes as a result of daylight savings. Britain does have a form of
>  daylight savings (referred to as British Summer Time or BST), but that is
>  defined as GMT+1 (GMT itself doesn't change).

James is correct.

>  As I understand it, the difference between UTC and GMT has to do with
> atomic
>  time measurement vs. astronomical calculations. For the most part the
>  differences are insignificant.

GMT [1] and UTC [2] have been the same thing since 1972 (also referred
to as 'Zulu' time - hence the 'Z' you sometimes see appended to UTC
date/time stamps).

The 'C' in UTC refers to co-ordination by the "International Earth
Rotation and Reference Systems Service" [3] of atomic clocks in
Greenwich, Paris and at the US Naval Observatory (which then updates
the GPS satellites so we don't get lost using our geo-location
gizmos).

[1] http://wikipedia.org/wiki/GMT
[2] http://wikipedia.org/wiki/UTC
[3] http://wikipedia.org/wiki/IERS

Regards,
Alan Dean
http://thoughtpad.net/alan-dean
http://simplewebservices.org

--- In rss-public@yahoogroups.com, Geoffrey Sneddon <foolistbar@...>
wrote:
> There was discussion in the time leading up to the vote on the 1.0
> version of the profile about work for the second edition (which was
> referred to as "1.1") — as far as I can see nothing at all has
> happened about this (I expect due to time constraints).

I think it would be a mistake to begin a new version of the profile so
soon. If people think it's a moving target, they'll be less likely to
implement the suggestions.

We've been focusing on helping developers and publishers implement the
profile, and have had success in that area. Since it was published in
October, both Six Apart and Wordpress  have made changes to pass all
profile-related checks in the Feed Validator.

gunnarsunshine wrote:
> It appears that implementing an RSS news reader may be a lot of work to
> do. At least when
> one reads the web page
> http://diveintomark.org/archives/2004/02/04/incompatible-rss
>
> Is the above mentioned web page accurate in its description of
> incompatibility?

I don't believe there's anything factually inaccurate on that page, however
the practical implications are vastly overstated, assumedly for dramatic
effect. It makes for entertaining reading, but it's not a great practical
resource.

Implementing an RSS reader can be a lot of work, but that has more to do
with the realities of parsing malformed feeds than it does with multiple RSS
versions.

Regards
James

I wouldn't worry about malformed feeds either. Rmail never tried to
parse malformed feeds. Whenever a user brought it up, I pointed to
the validators and CCed the publisher. Eventually, I sold Rmail to
NBC. I think the value of parsing malformed feeds is overstated as
well.
Thanks,

Randy

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
>
> Implementing an RSS reader can be a lot of work, but that has more
to do
> with the realities of parsing malformed feeds than it does with
multiple RSS
> versions.
>
> Regards
> James
>

Mark Pilgrim (the author of that article) has created an open source
library for parsing RSS feeds that takes all of the incompatibilities
and other issues into account:

http://www.feedparser.org/

On 23 Feb 2008, at 21:18, rcade wrote:

> --- In rss-public@yahoogroups.com, Geoffrey Sneddon <foolistbar@...>
> wrote:
>> There was discussion in the time leading up to the vote on the 1.0
>> version of the profile about work for the second edition (which was
>> referred to as "1.1") — as far as I can see nothing at all has
>> happened about this (I expect due to time constraints).
>
> I think it would be a mistake to begin a new version of the profile so
> soon. If people think it's a moving target, they'll be less likely to
> implement the suggestions.

I don't think that's true — people are still implementing WCAG 1.0
despite 2.0 getting closer to being to a REC. Also, I think if it's on
a timescale of around a year (which I wouldn't be surprised if it took
to get another version done).

> We've been focusing on helping developers and publishers implement the
> profile, and have had success in that area. Since it was published in
> October, both Six Apart and Wordpress  have made changes to pass all
> profile-related checks in the Feed Validator.

Those two probably account for a large amount of the RSS feeds out
there (though, admittedly, uptake of new versions is always a
challenge). I don't think uptake of the profile is an issue.


--
Geoffrey Sneddon
<http://gsnedders.com/>

I've found a RSS publisher whose network of sites extends the item
element with two namespace attributes. I brought it up on the Feed
Validator user's list:

http://tinyurl.com/37hcvy

The validator current issues an interop warning when it finds
namespace attributes on core elements.

I agree that properly namespaced extensions to core elements should
not flag a warning, as a general principle in XML namespacing.

--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> I've found a RSS publisher whose network of sites extends the item
> element with two namespace attributes. I brought it up on the Feed
> Validator user's list:
>
> http://tinyurl.com/37hcvy
>
> The validator current issues an interop warning when it finds
> namespace attributes on core elements.
>

Version 2.3 of VTD-XML (http://vtd-xml.sf.net), the next generation
document-centric XML processing model, is now released. To download
the latest version please visit
http://sourceforge.net/project/showfiles.php?
group_id=110612&package_....

Below is a list of new features and enhancements in this version.


* VTDException is now introduced as the root class for all other VTD-
XML's exception classes (per suggestion of Max Rahder).
* Transcoding capability is now added for inter-document cut and
paste. You can cut a chuck of bytes in a UTF-8 encoded document and
paste it into a UTF-16 encoded document and the output document is
still well-formed.
* ISO-8859-10, ISO-8859-11, ISO-8859-12, ISO-8859-13, ISO-8859-14
and
ISO-8859-15 support has now been added
* Zero length Text node is now possible.
* Ability to dump in-memory copy of text is added.
* Various code cleanup, enhancement and bug fixes.


Below are some new articles related to VTD-XML


* Index XML documents with VTD-XML http://xml.sys-
con.com/read/453082.htm
* Manipulate XML content the Ximple Way
http://www.devx.com/xml/Article/36379
* VTD-XML: A new vision of XML
http://www.developer.com/xml/article.php/3714051
* VTD-XML: XML Processing for the future
http://www.codeproject.com/KB/cs/vtd-xml_examples.aspx

Hi,

In browsing the Best Practices profile [1], I note that the definition
of language in RSS is a bit stale. In particular, the profile implies
that only ISO 639 codes are valid and the link to RSS 0.91 codes is
slightly stale also.

In fact, the language tags defined by W3C are the same as IETF BCP 47
(currently represented by RFC 4646) and the codes, including the ISO
639 codes, are all included in an IANA maintained subtag registry. I
would like to suggest updating the Best Practices profile and other
documentation to reflect these changes.

[1] http://www.rssboard.org/rss-profile#element-channel-lan

Best Regards,

Addison

Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization WG

How about minor changes like recommending that multiple catigories on
one item or channel be kept together?

--- In rss-public@yahoogroups.com, Geoffrey Sneddon <foolistbar@...>
wrote:
>
>
> On 23 Feb 2008, at 21:18, rcade wrote:
>
> > --- In rss-public@yahoogroups.com, Geoffrey Sneddon <foolistbar@>
> > wrote:
> >> There was discussion in the time leading up to the vote on the
1.0
> >> version of the profile about work for the second edition (which
was
> >> referred to as "1.1") — as far as I can see nothing at all has
> >> happened about this (I expect due to time constraints).
> >
> > I think it would be a mistake to begin a new version of the
profile so
> > soon. If people think it's a moving target, they'll be less
likely to
> > implement the suggestions.
>
> I don't think that's true — people are still implementing WCAG 1.0
> despite 2.0 getting closer to being to a REC. Also, I think if it's
on
> a timescale of around a year (which I wouldn't be surprised if it
took
> to get another version done).
>
> > We've been focusing on helping developers and publishers
implement the
> > profile, and have had success in that area. Since it was
published in
> > October, both Six Apart and Wordpress  have made changes to pass
all
> > profile-related checks in the Feed Validator.
>
> Those two probably account for a large amount of the RSS feeds out
> there (though, admittedly, uptake of new versions is always a
> challenge). I don't think uptake of the profile is an issue.
>
>
> --
> Geoffrey Sneddon
> <http://gsnedders.com/>
>

I have been reading through the discussions on the Profile and it
occurred to me that the concept of coding style would be appropriate
to introduce somewhere. In this spec the order of the elements in any
given tag is free to be in any order you wish. There is a very good
reason for this and it is directly related to good style. Good style
says you should group code in a way that best serves the situation.

Situations vary greatly and no one order can serve even a majority of
the situations that could come up in rss coding. There is just too
many variable factors here. Is the code being generated by hand or by
program. Is it pure rss or are other namespace elements included.
Categories can be very varied. Not only can various catologing
systems be included but a feed could include elements that purely
match different categories. e.g I author a website for a festival
that has classical chamber and jazz performances. Each performances
is generally pure in it's style of music though other media besides
live music can be included. Music would be far too broad a category.
To truely serve the purpose of the category tag both styles of music
have to be included. The best order for the tags would vary according
to these factors and others.

Anyone subscribing to this group is probably a serious coder and
knows the flexibility in this spec is to allow good style and not
permission to go completely random. But these specs will be read by
people that are essentially at the cut and paste stage so the need
for good style should probably be mentioned say in a starting out
page.

We have a good set of clear specs here, a profile that will help
people keep out of trouble given the common usage of these specs, and
perhaps a set of guiding principles that we all here take for
granted, would be a good idea for the less experience using these
documents. Would have to be guiding principles because because we are
dealing with an area where the goal would be deciding what is
appropriate.

I hope I do not offend anyone with this message. I am use to a style
of arguement where you state all the important factors even if you
are sure your audience knows them. I have been tutoring people all my
life and I am a bit old now. By habit, anytime I come across
documents like this I ask myself who is the audience an if it is in
part people that may know little of the subject; would they get lost?
Step by step tutorials are great if they are illustrating the basic
ideas. Otherwise the novice has trouble moving on beyond the specific
examples given. If our goal here is to promote the common and good
use of this standard we do have some responsibility to the newcomer
trying to learn it with a weak base of knowledge in programming as
well as the hardcore professional.

A possible addition for a future profile.

File names should probably not be greater than 31 characters in length
for compatibility with OSes that don't allow longer file names (such
as Mac OS).

Dave

I would prefer to go w/ 11 character filenames so that we can support
MS-DOS as well. Smiley face.

Randy

--- In rss-public@yahoogroups.com, "Dave Winer" <dave.winer@...> wrote:
>
> A possible addition for a future profile.
>
> File names should probably not be greater than 31 characters in length
> for compatibility with OSes that don't allow longer file names (such
> as Mac OS).
>
> Dave
>

Mac OS 9 (and earlier) had a 31 character limit, and is deprecated and
no longer supported by it's maker.

If we DO choose to add filename limits (which isn't necessarily a bad
idea, although one I'm lukewarm about), it should be based on
*current* OS limits (WinXP+, Mac OS X, Linux 2.4+, etc.).


=========================================
Ryan Parman
Creator and Co-Developer
SimplePie

http://simplepie.org
http://twitter.com/simplepie




On Mar 25, 2008, at 6:03 PM, Randy Morin wrote:
> I would prefer to go w/ 11 character filenames so that we can support
> MS-DOS as well. Smiley face.
>
> Randy
>
> --- In rss-public@yahoogroups.com, "Dave Winer" <dave.winer@...>
> wrote:
>>
>> A possible addition for a future profile.
>>
>> File names should probably not be greater than 31 characters in
>> length
>> for compatibility with OSes that don't allow longer file names (such
>> as Mac OS).
>>
>> Dave
>>
>
>

Since Mac has now deprecated 31 character limits, then we should make
certain all RSS URLs are 32 character or longer ;-)

Randy

--- In rss-public@yahoogroups.com, Ryan Parman <lists@...> wrote:
>
> Mac OS 9 (and earlier) had a 31 character limit, and is deprecated
and
> no longer supported by it's maker.
>
> If we DO choose to add filename limits (which isn't necessarily a
bad
> idea, although one I'm lukewarm about), it should be based on
> *current* OS limits (WinXP+, Mac OS X, Linux 2.4+, etc.).
>
>

This is a bad idea.  The local software should be handling this.  Best to
leave it to the standard offered by the transport used to deliver it.  Leave
it to what http, ftp or the transport's own limits.

What's next, limits based on OS character set hindrances (or programmer
myopia)?  Or, worse yet, ASCII only?  No thanks.

No software should be handling a URL without some form of pre-processing
anyway (ie for security and/or buffer issues).  So it's trivial for it to
handle re-mapping overly long lengths or unusual characters.  This has no
place in the RSS spec.

-Bill Kearney
Sydnic8.com

----- Original Message -----

>A possible addition for a future profile.
>
> File names should probably not be greater than 31 characters in length
> for compatibility with OSes that don't allow longer file names (such
> as Mac OS).
>
> Dave

I agree.  The feed consumer should be able to dovetail with whatever
filename-shortening mechanism the host OS supports.

--- In rss-public@yahoogroups.com, "Bill Kearney" <wkearney@...> wrote:
>
> This is a bad idea.  The local software should be handling this.
Best to
> leave it to the standard offered by the transport used to deliver
it.  Leave
> it to what http, ftp or the transport's own limits.
>
> What's next, limits based on OS character set hindrances (or programmer
> myopia)?  Or, worse yet, ASCII only?  No thanks.
>
> No software should be handling a URL without some form of
pre-processing
> anyway (ie for security and/or buffer issues).  So it's trivial for
it to
> handle re-mapping overly long lengths or unusual characters.  This
has no
> place in the RSS spec.
>
> -Bill Kearney
> Sydnic8.com
>
> ----- Original Message -----
>
> >A possible addition for a future profile.
> >
> > File names should probably not be greater than 31 characters in length
> > for compatibility with OSes that don't allow longer file names (such
> > as Mac OS).
> >
> > Dave
>

> Finally Dave, if you now want to alter or change the meanings and
> intentions
> of your own original specification I think you should make a globalized
> public apology for having conducted yourself as an obstinate weasel

I second the motion.

But realistically, his narcissistic personality makes that utterly
impossible.

To be serious for a second, I think it might be a good idea to mention
in the profile the issue Dave raises here. We don't actually have to
recommend anything.
Thanks Dave,

Randy

--- In rss-public@yahoogroups.com, "Dave Winer" <dave.winer@...> wrote:
>
> A possible addition for a future profile.
>
> File names should probably not be greater than 31 characters in length
> for compatibility with OSes that don't allow longer file names (such
> as Mac OS).
>
> Dave
>

Nat Lanza recently wrote on Twitter, "Dear weblog authors: I pretty
much never want to have to figure out *which* of your feeds to
subscribe to. Pick a format and stick with it."

http://twitter.com/nlanza/statuses/776809841

I have the same thought every time I find a site that offers a choice
of its feed in RSS 1.0, RSS 2.0 or Atom formats. This approach
actively deters subscribers, because most web users have no idea how
to make this choice and it scares them off.

Should the RSS Advisory Board recommend that feed publishers offer
their feeds in one format only, whether they choose Atom, RSS 1.0 or
RSS 2.0 as that format?

* rcade <cadenhead@...> [2008-03-27 15:30]:
> Should the RSS Advisory Board recommend that feed publishers
> offer their feeds in one format only, whether they choose Atom,
> RSS 1.0 or RSS 2.0 as that format?

At the very least, it should be strongly recommended that if a
feed is offered in multiple formats, the `title` attributes of
all the autodiscovery links should be identical.

I know that Firefox will then consider them to be identical and
will make the choice of format on behalf of the user. It has been
too long for me to remember what other software acts the same
way, but it was a public discussion a long while ago and I know
that Firefox is not the only client that acts like that.

Client implementors should also be instructed to follow this
behaviour.

Of course, picking a single format is still the best course. That
is clearly not a technical recommendation, however. Interop is
not at stake, so it can only be informal advice. Including it as
such would be fine, and useful.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

[Cross-posting between lists. Original thread:
http://tech.groups.yahoo.com/group/rss-media/message/1105
]


On Apr 3, 2008, at 2:33 PM, Mick Fuzz wrote:
> How would this process work?

Honestly, I don't know that there IS an *official* process for
updating and improving Media RSS. The group inside Y! essentially
disbanded, and most of the people who were initially involved are gone
now.

It was fairly recently discussed in this group (and generally agreed
upon) that the management of the Media RSS spec would move to the RSS
Advisory Board, but I haven't heard anything new about it in the weeks
since that conversation took place.

http://tech.groups.yahoo.com/group/rss-media/message/1091

In the meantime, I'm planning to set up a wiki page where I can start
piecing together my proposed clarifications and changes. I'm hoping
that eventually, we'll get a more standardized process in place where
the community can propose changes and reach a consensus before
publishing a new version of the spec.


=========================================
Ryan Parman
Creator and Co-Developer
SimplePie

http://simplepie.org
http://twitter.com/simplepie

Somewhere I've viewed an RSS (if I remember correctly RSS 2.0) file
with single <category> tag but two categories separated with '+' sign.
Something like this:

<category>Music + Dreams</category>

Should my RSS aggregator which I currently write consider this as two
categories? What is this plus-separated format: standard, common
practice, or just a little mis-behavior of marginal users? Is it
necessary to take it into account?

It would be incorrect to interpret this as two categories. It's
actually one category called "Music + Dreams". Two categories should be
two category elements. I'm not aware of any major publishers that are
making this mistake. James might know better.
MHO,

Randy
http://www.therssweblog.com

--- In rss-public@yahoogroups.com, "Victor Porton" <porton@...> wrote:
>
> Somewhere I've viewed an RSS (if I remember correctly RSS 2.0) file
> with single <category> tag but two categories separated with '+' sign.
> Something like this:
>
> <category>Music + Dreams</category>
>
> Should my RSS aggregator which I currently write consider this as two
> categories? What is this plus-separated format: standard, common
> practice, or just a little mis-behavior of marginal users? Is it
> necessary to take it into account?
>