FriendFeed is working on Simple Update Protocol (SUP), a means of
discovering when feeds on a particular service have been updated
without polling the individual feeds:

http://code.google.com/p/simpleupdateprotocol/

Feeds indicate their updates can be tracked with SUP by using a new
channel-link tag, as in this example from an Atom feed:

<link rel="http://api.friendfeed.com/2008/03#sup"
href="http://friendfeed.com/api/sup.json#53924729"
type="application/json" />

The rel attribute identifies an ID for the feed, called its SUP-ID.
The href attribute contains a URL that uses JSON data to identify
updated feeds by their SUP-IDs.

My first take on the protocol is that defining a relationship with a
URI is too different than standard link relationships in HTML:

http://www.w3.org/TR/REC-html40/types.html#type-links

Also, neither RSS 1.0 nor RSS 2.0 allows multiple channel-link tags,
so this would only be valid in an Atom feed.

Both of these concerns could be addressed by identifying the SUP
provider with a new namespace like this:

<rss xmlns:sup="http://friendfeed.com/api/sup/">
<channel>
<sup:provider href="http://friendfeed.com/api/sup.json#53924729"
type="application/json" />
...

If the definition of the channel-cloud element wasn't tied so closely
to remote procedure calls, it could have been used to identify a sup
provider.

After posting I found an alternative idea employed by Six Apart -- an
update stream in Atom format with updates from any TypePad or Vox blog:

http://updates.sixapart.com/

There's also something Radio UserLand does -- a channel-category tag:

<category
domain="http://rpc.weblogs.com/shortChanges.xml">rssUpdates>/category>

The domain is a changes.xml file on a Weblogs.Com-style ping server.

I added an issue to SUP's home page on Code.Google.Com about the use
of invalid RSS:

http://code.google.com/p/simpleupdateprotocol/issues/detail?id=3

That page permits comments, so it's a way to reach the SUP creators
with feedback on this issue and others.

Hello,

On Sat, Dec 6, 2008 at 7:48 AM, rcade <cadenhead@...> wrote:
> FriendFeed is working on Simple Update Protocol (SUP), a means of
> discovering when feeds on a particular service have been updated
> without polling the individual feeds:
>
> http://code.google.com/p/simpleupdateprotocol/
>
> Feeds indicate their updates can be tracked with SUP by using a new
> channel-link tag, as in this example from an Atom feed:
>
> <link rel="http://api.friendfeed.com/2008/03#sup"
> href="http://friendfeed.com/api/sup.json#53924729"
> type="application/json" />
>
> The rel attribute identifies an ID for the feed, called its SUP-ID.
> The href attribute contains a URL that uses JSON data to identify
> updated feeds by their SUP-IDs.
>
> My first take on the protocol is that defining a relationship with a
> URI is too different than standard link relationships in HTML:
>
> http://www.w3.org/TR/REC-html40/types.html#type-links

AFAIK, Atom requires you to use URLs for non-standard "rel" attribute
values.  So what SUP is doing for the "rel" attribute is correct.

> Also, neither RSS 1.0 nor RSS 2.0 allows multiple channel-link tags,
> so this would only be valid in an Atom feed.
>
> Both of these concerns could be addressed by identifying the SUP
> provider with a new namespace like this:
>
> <rss xmlns:sup="http://friendfeed.com/api/sup/">
> <channel>
> <sup:provider href="http://friendfeed.com/api/sup.json#53924729"
> type="application/json" />
> ...

You could also just use Atomic RSS...

http://www.tbray.org/ongoing/When/200x/2005/07/27/Atomic-RSS

... and get...

<rss xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<atom:link rel="http://api.friendfeed.com/2008/03#sup"
href="http://friendfeed.com/api/sup.json#53924729"
type="application/json" />
...

That way SUP looks basically the same in Atom and RSS.

--
Charles Iliya Krempeaux, B.Sc.
http://changelog.ca/

--- In rss-public@yahoogroups.com, "Charles Iliya Krempeaux"
<supercanadian@...> wrote:
> AFAIK, Atom requires you to use URLs for non-standard "rel" attribute
> values.  So what SUP is doing for the "rel" attribute is correct.

Interesting -- I wasn't aware of that. I tried to check it in the Atom
format spec, but I don't understand this sentence:

"The value of "rel" MUST be a string that is non-empty and matches
either the "isegment-nz-nc" or the "IRI" production in [RFC3987]."

http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.l\
ink

Which part of that means it's OK to define new relationships as IRIs
instead of getting IANA approval for your new rel value?

> <atom:link rel="http://api.friendfeed.com/2008/03#sup"
> href="http://friendfeed.com/api/sup.json#53924729"
> type="application/json" />
> ...

Are you aware of any IRI-based relationships that are currently in use
employing atom:link in feeds?

* rcade <cadenhead@...> [2008-12-07 02:15]:
> I tried to check it in the Atom format spec, but I don't
> understand this sentence:
>
> "The value of "rel" MUST be a string that is non-empty and
> matches either the "isegment-nz-nc" or the "IRI" production in
> [RFC3987]."
>
>
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.l\
ink
>
> Which part of that means it's OK to define new relationships as
> IRIs instead of getting IANA approval for your new rel value?

The sentence directly following that one.

     If a name is given, implementations MUST consider the link
     relation type equivalent to the same name registered within
     the IANA Registry of Link Relations (Section 7), and thus to
     the IRI that would be obtained by appending the value of the
     rel attribute to the string
     "http://www.iana.org/assignments/relation/".

IANA is the authority for iana.org URIs, but you are free to use
your own.

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

Hello,

On Sat, Dec 6, 2008 at 5:13 PM, rcade <cadenhead@...> wrote:
> --- In rss-public@yahoogroups.com, "Charles Iliya Krempeaux"
>
> <supercanadian@...> wrote:

[...]

> Are you aware of any IRI-based relationships that are currently in use
> employing atom:link in feeds?

Well, obviously anyone can create an Atom
URL/URI/IRI/whatever-you-want-to-call-them "rel" extension... and I've
even done it for "in house" software.  But I'm guessing you mean ones
in the wild.  Well there's SUP.  Atom threading was initially
done/proposed that way too I think.  (See:
http://www.ibm.com/developerworks/xml/library/x-atom10.html for
example.)  But I don't really know of any others.

--
Charles Iliya Krempeaux, B.Sc.
http://changelog.ca/

rcade wrote:
>
> Also, neither RSS 1.0 nor RSS 2.0 allows multiple channel-link tags,
> so this would only be valid in an Atom feed.

Neither place any limits on the number of atom:link elements in such
contexts.  Atom links with a rel="self" are already commonplace in RSS
2.0 feeds.

- Sam Ruby

--- In rss-public@yahoogroups.com, Sam Ruby <rubys@...> wrote:
> Neither place any limits on the number of atom:link elements in such
> contexts.  Atom links with a rel="self" are already commonplace in
> RSS 2.0 feeds.

True. But the documentation for SUP doesn't say that RSS publishers
should use atom:link in their feeds to define a provider. The docs
just say to add a link tag.

Hello


On Sat, Dec 6, 2008 at 8:45 AM, rcade <cadenhead@...> wrote:
> After posting I found an alternative idea employed by Six Apart -- an
> update stream in Atom format with updates from any TypePad or Vox blog:
>
> http://updates.sixapart.com/
>
> There's also something Radio UserLand does -- a channel-category tag:
>
> <category
> domain="http://rpc.weblogs.com/shortChanges.xml">rssUpdates>/category>
>
> The domain is a changes.xml file on a Weblogs.Com-style ping server.

Seems like quite the hack.

--
Charles Iliya Krempeaux, B.Sc.
http://changelog.ca/

rcade wrote:
> Are you aware of any IRI-based relationships that are currently in use
> employing atom:link in feeds?

I know Google uses IRI-based relationships in number of their feeds. Have a
look on Google calendar and Picasa for some examples.

Not that I'd necessarily recommend anything that Google is doing, but if
you're just looking for examples...

Regards
James

Hi everyone,

Is there a function in php to check if the date is in the RFC-822 date
format? I would greatly appreciate your help.

prashan

--- In rss-public@yahoogroups.com, "prashan"
<prashan_wanigasekara@...> wrote:
> Is there a function in php to check if the date is in the RFC-822 date
> format? I would greatly appreciate your help.

What language are you coding in?

Hi,

I try to be precise in a generic and popularized RSS definition for non
coders.

RSS is an XML dialect. It can handle external namespaces declared by "xmlns"
attributes.

But, hum, do you consider RSS as "namespace" in itself ? Or is it incorrect
to use this word.

In fact, I try to explain "namespace", in an RSS/Atom and modules/extensions
view, describing it as a group of elements all possibly used in a specific
goal, and needing to be declared to avoid polysemic confusion.

But how would you explain that RSS is a namespace... but that you don't have
to declare it the usual way...  (with "xmlns") ? Is the "<rss
version=2.0>... </rss>" section enough to say that the RSS namespace is the
basic namespace I the newsfeed ?

Thanks

secou

* secou <secou@...> [2009-02-02 16:30]:
> RSS is an XML dialect.

“RSS is an XML vocabulary.”

> It can handle external namespaces declared by "xmlns"
> attributes.

“It can incorporate other vocabularies if they have a namespace.
Namespaces must be declared with `xmlns` attributes.”

> But, hum, do you consider RSS as "namespace" in itself? Or is
> it incorrect to use this word.

No. Yes.

> In fact, I try to explain "namespace", in an RSS/Atom and
> modules/extensions view, describing it as a group of elements
> all possibly used in a specific goal, and needing to be
> declared to avoid polysemic confusion.
>
> But how would you explain that RSS is a namespace... but that
> you don't have to declare it the usual way...  (with "xmlns") ?
> Is the "<rss version=2.0>... </rss>" section enough to say that
> the RSS namespace is the basic namespace I the newsfeed ?

See above.

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

I've always found this mildly problematic.  Ideally, you should be
able to define a namespace for RSS and prefix the elements, but I
imagine that would break 99% of RSS clients, who aren't expecting RSS
elements to be prefixed at all.

--- In rss-public@yahoogroups.com, Aristotle Pagaltzis <pagaltzis@...>
wrote:
>
> * secou <secou@...> [2009-02-02 16:30]:
> > RSS is an XML dialect.
>
> “RSS is an XML vocabulary.”
>
> > It can handle external namespaces declared by "xmlns"
> > attributes.
>
> “It can incorporate other vocabularies if they have a namespace.
> Namespaces must be declared with `xmlns` attributes.”
>
> > But, hum, do you consider RSS as "namespace" in itself? Or is
> > it incorrect to use this word.
>
> No. Yes.
>
> > In fact, I try to explain "namespace", in an RSS/Atom and
> > modules/extensions view, describing it as a group of elements
> > all possibly used in a specific goal, and needing to be
> > declared to avoid polysemic confusion.
> >
> > But how would you explain that RSS is a namespace... but that
> > you don't have to declare it the usual way...  (with "xmlns") ?
> > Is the "<rss version=2.0>... </rss>" section enough to say that
> > the RSS namespace is the basic namespace I the newsfeed ?
>
> See above.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>

* scamden <sterling@...> [2009-02-03 01:25]:
> Ideally, you should be able to define a namespace for RSS and
> prefix the elements

1. The syntax which you might use for this actually undeclares
    the prefix. You can’t actually declare a prefix for the null
    namespace.

2. What would be the point? The elements stil aren’t in any
    namespace.

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

If you wanted to use the null namespace for some other purpose, then
you could prefix the RSS elements with a properly declared namespace
prefix (in an ideal world, and in standard XML grammar).  But RSS has
traditionally been used without any prefixes, and clients expect it
that way.  I'm not asking for a change, I'm just pining for the
fjords.

--- In rss-public@yahoogroups.com, Aristotle Pagaltzis <pagaltzis@...>
wrote:
>
> * scamden <sterling@...> [2009-02-03 01:25]:
> > Ideally, you should be able to define a namespace for RSS and
> > prefix the elements
>
> 1. The syntax which you might use for this actually undeclares
>    the prefix. You can’t actually declare a prefix for the null
>    namespace.
>
> 2. What would be the point? The elements stil aren’t in any
>    namespace.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>

* scamden <sterling@...> [2009-02-03 03:00]:
> If you wanted to use the null namespace for some other purpose,
> then you could prefix the RSS elements with a properly declared
> namespace prefix (in an ideal world, and in standard XML
> grammar). But RSS has  traditionally been used without any
> prefixes, and clients expect it that way. I'm not asking for a
> change, I'm just pining for the fjords.

I tried that with Atom, which *is* in a namespace, and even then
most clients broke: http://plasmasturm.org/log/376/

The situation is greatly improved now among the popular
aggregators but I have no doubt that lots of fringe software is
still broken in this respect.

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

I think there's two scenarios that exist with RSS vis-a-vis
namespaces.
-RSS elements in RSS documents
-RSS elements in other XML documents

1. RSS elements in RSS documents

These RSS element are not in a namespace. This inevitably brings
about debate. Some suggest that there is some sort of null XML
namespace, but nobody has ever shown me where this is defined. Please
do call me on this.

2. RSS elements in other XML documents

Nobody has ever made any formal proposal on this. The closest we ever
came was PSS, which I'm unsure if it was a joke, but Dave Winer never
moved it forward.
http://www.ibt4im.com/?guid=20030615083037

I think it's time to proposal PSS for adoption by the RSS Advisory
Board in order to clarify use of RSS in other XML documents.

Thoughts and criticism welcome and wanted.

Randy
http://www.therssweblog.com


--- In rss-public@yahoogroups.com, "secou" <secou@...> wrote:
>
> Hi,
>
> I try to be precise in a generic and popularized RSS definition for
non
> coders.
>
> RSS is an XML dialect. It can handle external namespaces declared
by "xmlns"
> attributes.
>
> But, hum, do you consider RSS as "namespace" in itself ? Or is it
incorrect
> to use this word.
>
> In fact, I try to explain "namespace", in an RSS/Atom and
modules/extensions
> view, describing it as a group of elements all possibly used in a
specific
> goal, and needing to be declared to avoid polysemic confusion.
>
> But how would you explain that RSS is a namespace... but that you
don't have
> to declare it the usual way...  (with "xmlns") ? Is the "<rss
> version=2.0>... </rss>" section enough to say that the RSS
namespace is the
> basic namespace I the newsfeed ?
>
> Thanks
>
> secou
>

Dave Winer's original suggestion of a portable RSS format is now
available here:

http://www.rssboard.org/news/186

The original is gone from Harvard's blog server.

Reading that post and Randy's PSS 0.9 draft, I agree that we need a
way to use RSS elements in other XML dialects. But I'm not convinced
that the simplest way to do this would be to create a new format.

I think we should consider adding a sentence to the end of the
Extending RSS section [1]:

"Using RSS elements in other XML dialects requires the namespace
declaration "http://www.rssboard.org/rss-namespace/". This declaration
MUST NOT be used in an RSS document."

The preceding paragraph currently states that RSS elements "are not
themselves members of a namespace" for backwards compatibility.

I like this suggestion. Unless someone objects, I will propose it to
the advisory board. I'll give this board a couple days to vent.

Randy
http://www.therssweblog.com


--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> Dave Winer's original suggestion of a portable RSS format is now
> available here:
>
> http://www.rssboard.org/news/186
>
> The original is gone from Harvard's blog server.
>
> Reading that post and Randy's PSS 0.9 draft, I agree that we need a
> way to use RSS elements in other XML dialects. But I'm not convinced
> that the simplest way to do this would be to create a new format.
>
> I think we should consider adding a sentence to the end of the
> Extending RSS section [1]:
>
> "Using RSS elements in other XML dialects requires the namespace
> declaration "http://www.rssboard.org/rss-namespace/". This
declaration
> MUST NOT be used in an RSS document."
>
> The preceding paragraph currently states that RSS elements "are not
> themselves members of a namespace" for backwards compatibility.
>

rcade wrote:
> I think we should consider adding a sentence to the end of the
> Extending RSS section [1]:
>
> "Using RSS elements in other XML dialects requires the namespace
> declaration "http://www.rssboard.org/rss-namespace/". This declaration
> MUST NOT be used in an RSS document."

My concern is that, no matter what you say in the spec, you can be sure that
people will start using that namespace in regular feeds. And when they do, I
suspect many feed readers are going to break.

I think we can possibly lessen that breakage by choosing a namespace URI
that is already in use in the wild, so there's some chance that feed readers
will already support it. The one that I've seen most often is:
http://backend.userland.com/rss2

Before this amendment is proposed to the board, I would like to run a few
tests to see how big an issue this is and if the choice of namespace URI
makes any real difference.

Regards
James

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
> I think we can possibly lessen that breakage by choosing a namespace
URI
> that is already in use in the wild, so there's some chance that feed
readers
> will already support it. The one that I've seen most often is:
> http://backend.userland.com/rss2

I look forward to seeing the results of your test, but since that URI
was used to define a namespace for RSS 2.0, won't that be received as
an encouragement to do exactly that?

Also, that URI lacks a trailing slash, and it's not under our control,
so we can't educate anyone who requests it in a browser on the proper
and improper use of namespace declarations in RSS.

We've had good success thus far in directing implementers to proper
use, through the spec, profile and the work with the Feed Validator
crew. The spec is clear on the lack of a namespace in RSS.

I will wait till you report back before I do anything.

Randy
http://www.therssweblog.com

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
>
> Before this amendment is proposed to the board, I would like to run a
few
> tests to see how big an issue this is and if the choice of namespace
URI
> makes any real difference.
>
> Regards
> James
>

rcade wrote:
> I look forward to seeing the results of your test,

Results now up on my blog:
http://www.xn--8ws00zhy3a.com/blog/2009/02/a-namespace-for-rss

> but since that URI
> was used to define a namespace for RSS 2.0, won't that be received as
> an encouragement to do exactly that?

I wouldn't think so. I may be wrong, but I was under the impression that
Dave experimented with it briefly in his feed, but never formally proposed
it be used for anything.

> Also, that URI lacks a trailing slash, and it's not under our control,
> so we can't educate anyone who requests it in a browser on the proper
> and improper use of namespace declarations in RSS.

I don't see the value of a trailing slash - the Atom namespace doesn't have
one and that has never been an issue AFAIK. The fact that it's not under the
board's control is a valid point though.

However, given that the namespace is in use in the wild and is conciously
supported by at least a few feed readers, I think creating a new namespace
assigned to the same set of elements is a bad idea. We could end up with the
same chaos we have with the Yahoo media rss extension, with different people
using different namespaces, and it'll end up an interoperability nightmare.

Regards
James

Thanks James!

There is only 7 clients that support the userland namespace and
wouldn't support a new namespace. I would go with a new namespace and
a bold warning against using the namespace in RSS documents. In fact,
I'm putting a warning on this thread, just in case.

    !!!WARNING!!!!
In no way should anybody interpret anything in this thread or any
spec changes resulting from this thread as permission to use a
namespace for RSS 2.0 elements in an RSS 2.0 document.
    !!!WARNING!!!!

Further, I wouldn't require the use of the namespace, but rather
suggest the use of the namespace when and only when it helps embed
RSS elements in other documents.

MHO,

Randy
http://www.therssweblog.com


--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
> Results now up on my blog:
> http://www.xn--8ws00zhy3a.com/blog/2009/02/a-namespace-for-rss
>

On 5 Feb 2009, at 05:20, James Holderness wrote:

> rcade wrote:
>> I look forward to seeing the results of your test,
>
> Results now up on my blog:
> http://www.xn--8ws00zhy3a.com/blog/2009/02/a-namespace-for-rss

FWIW, SimplePie used to support the Userland namespace, but dropped
support for it seeming it was used nowhere and does have a cost. It
appears (looking with grep�) to have been introduced for 1.0 Beta 2
and removed for 1.0 RC1 (i.e., the last release with support was 1.0
Beta 3 Bugfix 2). However, these versions oddly seem to match
element's expanded names case-insensitively (I'm sure I thought there
was some good compat. reason for this at the time). Furthermore,
versions prior to 1.0 Beta 2 (though maybe not 0.8, but I never had
anything to do with that) will have worked with all but the prefixed
variations (due to not using a namespace-aware XML parser).

To my knowledge, nothing broke by moving to a namespace-aware parser,
and nothing broke removing support for the Userland namespace.


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

On 4 Feb 2009, at 04:57, rcade wrote:

> Reading that post and Randy's PSS 0.9 draft, I agree that we need a
> way to use RSS elements in other XML dialects. But I'm not convinced
> that the simplest way to do this would be to create a new format.
>
> I think we should consider adding a sentence to the end of the
> Extending RSS section [1]:
>
> "Using RSS elements in other XML dialects requires the namespace
> declaration "http://www.rssboard.org/rss-namespace/". This declaration
> MUST NOT be used in an RSS document."

To give my opinion as an implementer: do we really need another feed
format? Effectively, aggregators have support RSS 0.90, RSS 2.0, Atom
0.3, and Atom 1.0 � do we really have to add RSS-2.0-in-a-namespace to
that list?

Although we wouldn't have to support it as a feed format per-se, what
we would have to do would amount to supporting it for everything
except as a root element (for the sake of supporting, e.g.,
{http://www.rssboard.org/rss-namespace/
}title within an Atom document). I'm also dubious about that "MUST
NOT" � history has taught us content creators often ignore specs, and
I would not be surprised if we had to add support for it as a document
format (though with support for it within Atom that'd mainly be an
already sunk cost).

Furthermore, I'm doubtful of the real need for RSS-in-a-namespace:
what does RSS-in-a-namespace give us that Atom can't already do?
Unless a good answer can be found to that question, I'm against
creating (what amounts to) another XML format.


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

You don't and nobody has to support the userland namespace. I don't
have any stats, but I'm betting that almost nobody uses it.
Thanks,

Randy

--- In rss-public@yahoogroups.com, Geoffrey Sneddon <foolistbar@...>
wrote:
>