What's the problem? RSS is an application of XML and XML has already
solved the Unicode problem.

Randy Charles Morin
http://www.therssweblog.com


--- In rss-public@yahoogroups.com, "Clinton Gallagher"
<csgallagher@...> wrote:
> The problem I'm struggling with right now is Unicode and wondering
how the
> heck to build Unicode validation into the ASP.NET feed builder I've been
> working on.
>
> <%= Clinton Gallagher
>

<snip />

The problem as I thought it would be understood is validating Unicode
characters submitted to a form in an application developed to save the data
using an XML file.

This is only unique to RSS in the sense that the topic of this list article
happens to be concerned with webfeed content presumably created using some
language other than English.

At the moment I'm belaboring the belief that all textboxes in my application
which are used to transport localized content must do so using Unicode
rather than English expressed as ASCII text. This is after all an 8-bit vs
16-bit paradigm is it not?

Also of concern is the presumption that each XML element or its attributes
which encapsulate data are best accomplished using CDATA syntax within the
XML element or its attributes.

<%= Clinton Gallagher


> 1b. Re: Translations of RSS specs
>     Posted by: "Randy Morin" randy@... randymorin
>     Date: Tue May 1, 2007 8:04 am ((PDT))
>
> What's the problem? RSS is an application of XML and XML has already
> solved the Unicode problem.
>
> Randy Charles Morin
> http://www.therssweblog.com
>
>
> --- In rss-public@yahoogroups.com, "Clinton Gallagher"
> <csgallagher@...> wrote:
> > The problem I'm struggling with right now is Unicode and wondering
> > how the heck to build Unicode validation into the ASP.NET feed
> > builder I've been working on.
> >
> > <%= Clinton Gallagher
> >

When using ASP.NET, you can simply use the XmlWriter and XmlDocument
classes and the framework takes care of most all the Unicode issues
for you. A problem often arises when developers try to build XML
documents using the default output building technique.

This is a sample of the default output building an RSS file.
<% Page ... %>
<rss verison="2.0>
    more code here
</rss.
This is inherently buggy. It doesn't even guarantee well-formedness.
Try this instead.
<% Page ... %>
<%
    XmlDocument doc = MyDoc;
    doc.Save(Response.OutputStream);
%>
Guaranteed well-formedness. Less likely that you need to worry about
encodings.

Hope this helps and is clear.

Randy Charles Morin
http://www.therssweblog.com/


--- In rss-public@yahoogroups.com, "Clinton Gallagher"
<csgallagher@...> wrote:
>
> <snip />
>
> The problem as I thought it would be understood is validating Unicode
> characters submitted to a form in an application developed to save
the data
> using an XML file.
>
> This is only unique to RSS in the sense that the topic of this list
article
> happens to be concerned with webfeed content presumably created
using some
> language other than English.
>
> At the moment I'm belaboring the belief that all textboxes in my
application
> which are used to transport localized content must do so using Unicode
> rather than English expressed as ASCII text. This is after all an
8-bit vs
> 16-bit paradigm is it not?
>
> Also of concern is the presumption that each XML element or its
attributes
> which encapsulate data are best accomplished using CDATA syntax
within the
> XML element or its attributes.
>
> <%= Clinton Gallagher
>
>

Clinton Gallagher wrote:
> <snip />
>
> The problem as I thought it would be understood is validating Unicode
> characters submitted to a form in an application developed to save the data
> using an XML file.

There actually are two sets of problems here.  One is that XML 1.0
limits which Unicode characters may be included in an XML document.

http://www.w3.org/TR/REC-xml/#charsets

Additionally, one Unicode character may be encoded as one, two, three,
or more bytes, depending on the encoding.  All you can ever really
verify is the bytes, and only to the extent that the bytes map to
*something*.

Two common encodings, to illustrate:

iso-8859-1 is common (particularly in web content), and in this encoding
all supported Unicode characters are represented as exactly one byte
(which means that this encoding only supports exactly 256 Unicode
characters), and furthermore every byte value is "valid".  But there are
two ranges (0x00-0x1F and 0x7F-0x9F) which are non-displayable control
characters, so these would not typically be expected in a feed.  Some of
these characters also are disallowed in XML (per above).

utf-8 is also common (particularly in XML content), and can support all
Unicode characters, but only certain high-bit sequences are valid.  The
rules are a bit involved, but are captured by the regular expression
described here:

http://www.w3.org/International/questions/qa-forms-utf-8.en.php

(Note: that regular expression improperly mixes in checks for XML
restrictions, but that's OK in this context as we are talking about XML
feeds here).

As an aside, one surprisingly common error is for tools to take Unicode
characters, convert them to a stream of utf-8 bytes, then to take that
sequence of bytes and interpret them effectively as iso-8859-1
characters, and convert them (again!) to utf-8.  This is common enough
that the feed validator has a specific check to warn about such.

Related reading:

http://www.intertwingly.net/blog/2004/06/28/Trackback-in-valid-out-mostly
http://www.intertwingly.net/blog/2004/04/15/Character-Encoding-and-HTML-Forms

- Sam Ruby

Guys! I've translated RssCloud API and RSS Autodiscovery specs into
russian! So where should I post them.

--- In rss-public@yahoogroups.com, "Clinton
Gallagher" <csgallagher@...> wrote:
> The problem I'm struggling with right now is Unicode and wondering
how the
> heck to build Unicode validation into the ASP.NET feed builder I've
been
> working on.
>
> <%= Clinton Gallagher
>
Well i don't use ASP.NET and don't know what's that at all:) but i
advise you to go to www.msdn2.com/library/ and search something
sutable there. i hope there's something of interest among Technical
Articles/Tip etc.

If i'm lucky i'll start working tomorrow morning and call up my
friend about french version. I'll make a post when at least one of
them will be ready. I'm very busy now but i'll try to finish russian
trans. before this week-end.

Good luck in building Unicode validation!

I would put it on your website. Then we'll all link to it. Unless you
don't want the bandwidth, in that case, I could put it on
www.therssweblog.com or maybe Rogers can upload it to rssboard.org.
Thanks,

Randy

--- In rss-public@yahoogroups.com, "Serj I" <serjrds@...> wrote:
>
> Guys! I've translated RssCloud API and RSS Autodiscovery specs into
> russian! So where should I post them.
>

NewsGator is implementing the noindex meta tag, similar to what Yahoo is
doing.  I've chatted with the Yahoo folks about how we're treating
content with that tag - we have an archive of data, and we also index
historical content, so our implementation is a bit more complex than
theirs.  As soon as the implementation is done, I'll post on my blog the
specific semantics we're using.

Greg Reinacker
NewsGator Technologies, Inc.
http://www.newsgator.com



-----Original Message-----
From: rss-public@yahoogroups.com [mailto:rss-public@yahoogroups.com] On
Behalf Of Randy Morin
Sent: Monday, April 16, 2007 4:10 PM
To: rss-public@yahoogroups.com
Subject: [rss-public] Re: Yahoo Uses Meta Tag in RSS Feeds

This is likely an opportunity for us build some consensus.

Randy Charles Morin
http://www.therssweblog.com

--- In rss-public@yahoogroups.com, Sam Ruby <rubys@...> wrote:
>
> rcade wrote:
> > http://publisher.yahoo.com/rss_guide/faq.php
> >
> > There's an interesting use of the XHTML namespace recommended by
Yahoo
> > in its Publisher's Guide to RSS:
> >
> > How do I prevent my feeds from being listed in the search results
for
> > the Yahoo! Feed Database?
> >
> > The "Add Content" feature in My Yahoo! allows users to search the
> > Yahoo! Feed Database for available feeds. To prevent your feed from
> > being searched in the Yahoo! Feed Database, while still allowing
users
> > to subscribe to your content, add the following code to your feed:
> >
> > <meta xmlns="http://www.w3.org/1999/xhtml"
> >  name="robots" content="noindex" />
> >
> > Any thoughts on this approach, and whether it should be included in
> > the RSS Profile or extended with other meta tags?
>
> Bloglines:
>
> <access:restriction
> xmlns:access="http://www.bloglines.com/about/specs/fac-1.0"
> relationship="deny"/>
>
> Google/LiveJournal:
>
> xmlns:indexing="urn:atom-extension:indexing" indexing:index="no"
>
> - Sam Ruby
>





Yahoo! Groups Links

Thanks Greg,
This is likely an opportunity for consensus.

Randy

--- In rss-public@yahoogroups.com, "Greg Reinacker" <gregr@...> wrote:
>
> NewsGator is implementing the noindex meta tag, similar to what Yahoo is
> doing.  I've chatted with the Yahoo folks about how we're treating
> content with that tag - we have an archive of data, and we also index
> historical content, so our implementation is a bit more complex than
> theirs.  As soon as the implementation is done, I'll post on my blog the
> specific semantics we're using.
>
> Greg Reinacker
> NewsGator Technologies, Inc.
> http://www.newsgator.com
>
>
>
> -----Original Message-----
> From: rss-public@yahoogroups.com [mailto:rss-public@yahoogroups.com] On
> Behalf Of Randy Morin
> Sent: Monday, April 16, 2007 4:10 PM
> To: rss-public@yahoogroups.com
> Subject: [rss-public] Re: Yahoo Uses Meta Tag in RSS Feeds
>
> This is likely an opportunity for us build some consensus.
>
> Randy Charles Morin
> http://www.therssweblog.com
>
> --- In rss-public@yahoogroups.com, Sam Ruby <rubys@> wrote:
> >
> > rcade wrote:
> > > http://publisher.yahoo.com/rss_guide/faq.php
> > >
> > > There's an interesting use of the XHTML namespace recommended by
> Yahoo
> > > in its Publisher's Guide to RSS:
> > >
> > > How do I prevent my feeds from being listed in the search results
> for
> > > the Yahoo! Feed Database?
> > >
> > > The "Add Content" feature in My Yahoo! allows users to search the
> > > Yahoo! Feed Database for available feeds. To prevent your feed from
> > > being searched in the Yahoo! Feed Database, while still allowing
> users
> > > to subscribe to your content, add the following code to your feed:
> > >
> > > <meta xmlns="http://www.w3.org/1999/xhtml"
> > >  name="robots" content="noindex" />
> > >
> > > Any thoughts on this approach, and whether it should be included in
> > > the RSS Profile or extended with other meta tags?
> >
> > Bloglines:
> >
> > <access:restriction
> > xmlns:access="http://www.bloglines.com/about/specs/fac-1.0"
> > relationship="deny"/>
> >
> > Google/LiveJournal:
> >
> > xmlns:indexing="urn:atom-extension:indexing" indexing:index="no"
> >
> > - Sam Ruby
> >
>
>
>
>
>
> Yahoo! Groups Links
>

A new update to the RSS best-practices profile has been published.

http://www.rssboard.org/rss-profile-1-15

Added -- a new section on the atom:link element:

http://www.rssboard.org/rss-profile-1-15#namespace-elements-atom

Updated -- the to-do list, which contains everything that will be
covered before it is submitted to a vote of the RSS Advisory Board:

http://www.rssboard.org/rss-profile-1-15#to-do

Please leave your feedback here. This is a work in progress.

In my code I written
response.getWriter().write("<ttl>"+5+"</ttl>");  for ttl  but it's not
working. please suggest me how to do this tag in jsp. Means how I
define this time.

I published a new draft of the RSS best practices profile today:

http://www.rssboard.org/rss-profile

The only change is to remove Sam Ruby's name from the credits, per his
request:

http://www.rssboard.org/rss-profile#credits

I apologize to Sam for not doing this in yesterday's draft, as I had
said I would do last fall the next time the profile was updated.

>A new update to the RSS best-practices profile has been published.
>
> http://www.rssboard.org/rss-profile-1-15
>
> Added -- a new section on the atom:link element:
>
> http://www.rssboard.org/rss-profile-1-15#namespace-elements-atom

I have some minor issues with this addition. My understanding was that a
'via' relationship was to indicate a document that was the inspiration for
the post. For example, let's say you read about a new gizmo of some sort on
engadget. You want to tell your readers about it so you write your own post
on the subject. However, you want to credit engadget because they provided
you with the source of your story, so you include a 'via' link back to them.

If you were reposting someone else's article in its entirety (in a link
blog, for example) that's not the place for a 'via' link. In an Atom feed
you should be using an atom:source element to provide proper attribution and
it's the 'alternate' link that should point to the original web page.
Anything else would essentially be feed hijacking.

That said, I don't think any of this stuff belongs in the best practices
profile. Other than that specific case of a self link at the channel level,
I very much doubt any of those relationships are likely to be used or
supported in an RSS feed. AFAIK they aren't even supported in Atom feeds for
the most part. [1]

Regards
James

[1] http://intertwingly.net/wiki/pie/LinkConformanceTests

What exactly is not working about it?
Thanks,

Randy

--- In rss-public@yahoogroups.com, "Santanu Nandi" <becsantanu@...> wrote:
>
>
> In my code I written
> response.getWriter().write("<ttl>"+5+"</ttl>");  for ttl  but it's not
> working. please suggest me how to do this tag in jsp. Means how I
> define this time.
>

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
> That said, I don't think any of this stuff belongs in the best
> practices profile. Other than that specific case of a self link at the
> channel level, I very much doubt any of those relationships are likely
> to be used or supported in an RSS feed. AFAIK they aren't even
> supported in Atom feeds for the most part. [1]
>
> [1] http://intertwingly.net/wiki/pie/LinkConformanceTests

For namespaced elements described in the profile, my approach has been
to fully describe the element in its Requirements section.

If we don't, it gives RSS Profile readers a narrow and perhaps
misleading impression of what the element does.

For example, atom:link does a lot more than feed self linking. I don't
want profile readers who are unfamiliar with the element to think
that's all it does.

Clinton Gallagher has begun a discussion on RSS-DEV about the channel
image element that might be of interest:

http://tech.groups.yahoo.com/group/rss-dev/message/7427

> For example, atom:link does a lot more than feed self linking. I don't
> want profile readers who are unfamiliar with the element to think
> that's all it does.

My view is that the profile should be describing reality rather than theory.
In theory an atom:link can do a lot, but in reality it has only one very
specific use in RSS. I could understand including a link back to RFC4287 for
anyone that wants the official definition. That way we wouldn't be accused
of summarising badly either.

Look at it another way, if we were to describe RSS's xhtml:body usage in the
profile, would we feel obliged to describe all the attributes that can be
used with that element in an xhtml document? Even though none of them have
any application in RSS?

Regards
James

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
> My view is that the profile should be describing reality rather than
> theory.

That makes sense for the recommendations, but the profile also
describes requirements for elements. Although these descriptions are
not authorititive, they make it considerably easier to understand the
advice.

We're not limited for space here. If the profile gets too big, we can
break it out over multiple pages.

rcade wrote:
>> My view is that the profile should be describing reality rather than
>> theory.
>
> That makes sense for the recommendations, but the profile also
> describes requirements for elements. Although these descriptions are
> not authorititive, they make it considerably easier to understand the
> advice.

Ok, I can see your point, but I still think we can achieve the same thing
without providing that much detail. After all, it's not a *complete*
description of the atom:link element. It doesn't point out that the rel
attribute could also be any number of other registered link relations [1].
It doesn't point out that "http://www.iana.org/assignments/relation/self" is
semantically equivalent to "self". It doesn't point out that the default rel
is "alternate". It doesn't explain how xml:lang and xml:base might apply.

And rightly so, IMHO. A certain amount of background detail can be
informative, but too much is just confusing. Can we not find some kind of
middle ground? For example, we list all the attributes, but only describe in
detail the ones that are relevant to RSS (and how their usage might be
differ from Atom). We point out that the rel attribute can take a number of
values, but we don't actually list and describe every one of them - just the
ones that are relevant to RSS. Does something like that not seem reasonable?

Regards
James

[1] http://www.iana.org/assignments/link-relations/

// Section 2 Paragraph 2 states:
Software designed to retrieve and present RSS documents to users is called
an aggregator, newsreader or reader. For clarity, this specification uses
the term aggregator exclusively.

// Append the following immediately after Section 2 Paragraph 2
Software designed to create RSS documents is called a generator, a builder
or a writer. For clarity, this specification uses the term builder
exclusively.

<%= Clinton Gallagher

Notes

-Revisit the issue of whether RSS 2.0 allows namespaced attributes to
extend core elements

I would prefer that namespace attributes are allowed, but clearly the
spec was mis-written to deny them. I would rather address this problem
by modifying the spec, rather than cementing a typo.

Currently the spec says "A RSS feed may contain elements not described
on this page, only if those elements are defined in a namespace." We
could simply simply change the spec to say elements and attributes.

-Add the * namespace

I would simply remove all these or we'll never be done. They can be
added later in version 1.1 or 2.0.

-Consider adding a section on feed state

We can add feedstate as part of a 2.0 version.



--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> A new update to the RSS best-practices profile has been published.
>
> http://www.rssboard.org/rss-profile-1-15
>
> Added -- a new section on the atom:link element:
>
> http://www.rssboard.org/rss-profile-1-15#namespace-elements-atom
>
> Updated -- the to-do list, which contains everything that will be
> covered before it is submitted to a vote of the RSS Advisory Board:
>
> http://www.rssboard.org/rss-profile-1-15#to-do
>
> Please leave your feedback here. This is a work in progress.
>

Minor note

-Change copyright to 06-07

BTW, this looks awesome. The faster we get this approved, the better
off RSS would be.

Randy Charles Morin
http://www.therssweblog.com


--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> A new update to the RSS best-practices profile has been published.
>
> http://www.rssboard.org/rss-profile-1-15
>
> Added -- a new section on the atom:link element:
>
> http://www.rssboard.org/rss-profile-1-15#namespace-elements-atom
>
> Updated -- the to-do list, which contains everything that will be
> covered before it is submitted to a vote of the RSS Advisory Board:
>
> http://www.rssboard.org/rss-profile-1-15#to-do
>
> Please leave your feedback here. This is a work in progress.
>

Randy Morin wrote:
> Notes
>
> -Revisit the issue of whether RSS 2.0 allows namespaced attributes to
> extend core elements
>
> I would prefer that namespace attributes are allowed, but clearly the
> spec was mis-written to deny them. I would rather address this problem
> by modifying the spec, rather than cementing a typo.

Are you *sure* it was a typo?

I'm certain I can find people to advocate one or more of the following:

    * "I would prefer that multiple enclosures were permitted per item,
       but clearly the spec was mis-written to deny them.  I would
       rather address this problem by modifying the spec, rather than
       cementing a typo.

    * "I would prefer that HTML were allowed in titles, but clearly the
       spec was mis-written to deny them.  I would rather address this
       problem by modifying the spec, rather than cementing a typo."

    * "I would prefer that relative URIs were allowed in descriptions,
       but clearly the spec was mis-written to deny them.  I would
       rather address this problem by modifying the spec, rather than
       cementing a typo.

Where does it stop?

- Sam Ruby

From the spec: "A RSS feed may contain elements not described on this
page, only if those elements are defined in a namespace."

Question: How does this sentence forbid namespace attributes in core
elements *while* allowing them in namespace elements?

We're already assuming that namespace attributes are OK inside
namespace elements. Isn't the simplest assumption that they are
permitted everywhere in RSS?

--- In rss-public@yahoogroups.com, Sam Ruby <rubys@...> wrote:
> Are you *sure* it was a typo?
> I'm certain I can find people to advocate one or more of the
following ...

Fear of your slippery slope is one reason the spec hasn't been revised
to deal with some longstanding issues that wreak havoc among
implementers. Instead, the RSS Profile attempts to address things like
item enclosures in this manner:

Step 1: Tell people there's confusion or a difference of opinion.

Step 2: Document current use.

Step 3: Come up with a suggestion on how to best deal with the
situation, based on current use.

This approach doesn't work with the namespace attributes issue,
because namespaces function independently of each other. Microsoft's
addition of cf:type to item-description only affects implementers of
its namespace.

So the only way the board can help is to tell people what the
Extending RSS section of the spec means, based on the best information
we have available to us.

If Randy wants to change elements to "elements and attributes" as a
spec clarification, I'm comfortable solving the
problem in that manner.

The RSS profile draft has been updated to bring the profile up-to-date
with the draft spec and address one issue with skipHours.

http://www.rssboard.org/rss-profile

Major changes:

* In the following Character Data requirement, the first SHOULD was
previously called a MUST: "For all elements defined in the RSS
specification that enclose character data, the text SHOULD be
interpreted as plain text with the exception of an item's description
element, which MUST be suitable for presentation as HTML."

http://www.rssboard.org/rss-profile#data-types-characterdata

* The Email Addresses data type has been added to the profile:

http://www.rssboard.org/rss-profile#data-types-email

* The channel-skipHours-hour requirements section removes hour 24 from
this sentence: "Values from 0 to 23 are permitted, with 0 representing
midnight. An hour MUST NOT be duplicated."

The current spec is clear that hours are numbered from 0 to 23.
Treating Hour 24 exactly like Hour 0 is recommended for compatibility
reasons, since a past spec used 1-24 numbering instead of 0-23 numbering.

Minor changes:

* This sentence from item-pubDate has been removed: "See the date-time
section for general recommendations regarding date-time values in RSS."

The sentence is redundant, because the requirements section of this
element links to the Date-Time data type section already.

* The Data Types subsections are now alphabetized, moving Character
Data up to 3.1 and shifting the others accordingly.

* For clarity, an RSS feed is always described as a feed. References
to RSS document and RSS channel were changed.

* When an element contains data described in a Data Types section, the
element's description now links to that data type.

* In the Conventions section, two references that mistakenly called
the profile a "specification" have been fixed.

* Some references to the RSS 2.0 specification have been simplified.

Namespaces were added to RSS by Dave Winer in fall 2002, at a time
when the next version was going to be numbered RSS 0.94. (It was
renumbered RSS 2.0 at first publication.)

http://www.rssboard.org/rss-2-0

His intent in doing this was described in a Scripting News weblog post:

http://www.scripting.com/2002/09/06.html#When:10:56:56AM

"I've added the section explaining how to extend RSS through
namespaces. I'm basically telling you to ask the W3C how namespaces
work, and do it the way they tell you to do it. I don't want to assume
the problem of documenting namespaces in the RSS spec. Then I modified
the roadmap, it got a lot simpler. No more innovation. RSS is frozen.
Only minor adjustments are contemplated."

At the same time, he described his interpretation of the RSS 2.0 roadmap:

http://www.scripting.com/2002/09/06.html#theRoadToRss20

"Namespace support is no longer in the future, the core of RSS is
frozen, no features are deprecated (explain why), there may be a 2.01
and 2.02, for the purpose of clarification, but no new core elements
are anticipated."

This tells us a couple of things:

1. The author of RSS 2.0 had no intent to include namespace elements
while excluding namespace attributes. His intent was to defer entirely
to the XML in Namespaces specification.

2. He also anticipated future versions of RSS 2.0 for "minor
adjustments" and "for the purpose of clarification" but did not want
new core elements to be added.

One last comment regarding this issue. You can't use a namespace in
RSS without adding a declaration for the namespace, like so:

<rss version="2.0"
   xmlns:dc="http://purl.org/dc/elements/1.1/">
</rss>

The XML in Namespaces specification calls this declaration an attribute:

http://www.w3.org/TR/REC-xml-names/#ns-decl

"A namespace (or more precisely, a namespace binding) is declared
using a family of reserved attributes. Such an attribute's name must
either be xmlns or begin xmlns:. These attributes, like any other XML
attributes, may be provided directly or by default."

So if RSS forbids namespace attributes to core elements, doesn't that
forbid namespace declarations in the RSS element?

Since namespace declarations are specifically used in the spec, then
I'd make the leap that they are specifically allowed. I'd even go a
step further and say that any xml:* attributes are allowed because
these are not extensions, they are a basic part of any XML grammar.

Last, I'd repeat that worrying about an obviously typo is a
distraction. I'd rather just modify the spec to add clarity. That`s
clearly within our mandate.
Thanks,

Randy




--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> One last comment regarding this issue. You can't use a namespace in
> RSS without adding a declaration for the namespace, like so:
>
> <rss version="2.0"
>   xmlns:dc="http://purl.org/dc/elements/1.1/">
> </rss>
>
> The XML in Namespaces specification calls this declaration an
attribute:
>
> http://www.w3.org/TR/REC-xml-names/#ns-decl
>
> "A namespace (or more precisely, a namespace binding) is declared
> using a family of reserved attributes. Such an attribute's name must
> either be xmlns or begin xmlns:. These attributes, like any other
XML
> attributes, may be provided directly or by default."
>
> So if RSS forbids namespace attributes to core elements, doesn't
that
> forbid namespace declarations in the RSS element?
>

agreed

--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> Namespaces were added to RSS by Dave Winer in fall 2002, at a time
> when the next version was going to be numbered RSS 0.94. (It was
> renumbered RSS 2.0 at first publication.)
>
> http://www.rssboard.org/rss-2-0
>
> His intent in doing this was described in a Scripting News weblog
post:
>
> http://www.scripting.com/2002/09/06.html#When:10:56:56AM
>
> "I've added the section explaining how to extend RSS through
> namespaces. I'm basically telling you to ask the W3C how namespaces
> work, and do it the way they tell you to do it. I don't want to
assume
> the problem of documenting namespaces in the RSS spec. Then I
modified
> the roadmap, it got a lot simpler. No more innovation. RSS is
frozen.
> Only minor adjustments are contemplated."
>
> At the same time, he described his interpretation of the RSS 2.0
roadmap:
>
> http://www.scripting.com/2002/09/06.html#theRoadToRss20
>
> "Namespace support is no longer in the future, the core of RSS is
> frozen, no features are deprecated (explain why), there may be a
2.01
> and 2.02, for the purpose of clarification, but no new core elements
> are anticipated."
>
> This tells us a couple of things:
>
> 1. The author of RSS 2.0 had no intent to include namespace elements
> while excluding namespace attributes. His intent was to defer
entirely
> to the XML in Namespaces specification.
>
> 2. He also anticipated future versions of RSS 2.0 for "minor
> adjustments" and "for the purpose of clarification" but did not want
> new core elements to be added.
>

This is looking great. Thanks a lot for your great work Rogers.

Randy

--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> The RSS profile draft has been updated to bring the profile up-to-
date
> with the draft spec and address one issue with skipHours.
>
> http://www.rssboard.org/rss-profile
>
> Major changes:
>
> * In the following Character Data requirement, the first SHOULD was
> previously called a MUST: "For all elements defined in the RSS
> specification that enclose character data, the text SHOULD be
> interpreted as plain text with the exception of an item's
description
> element, which MUST be suitable for presentation as HTML."
>
> http://www.rssboard.org/rss-profile#data-types-characterdata
>
> * The Email Addresses data type has been added to the profile:
>
> http://www.rssboard.org/rss-profile#data-types-email
>
> * The channel-skipHours-hour requirements section removes hour 24
from
> this sentence: "Values from 0 to 23 are permitted, with 0
representing
> midnight. An hour MUST NOT be duplicated."
>
> The current spec is clear that hours are numbered from 0 to 23.
> Treating Hour 24 exactly like Hour 0 is recommended for
compatibility
> reasons, since a past spec used 1-24 numbering instead of 0-23
numbering.
>
> Minor changes:
>
> * This sentence from item-pubDate has been removed: "See the date-
time
> section for general recommendations regarding date-time values in
RSS."
>
> The sentence is redundant, because the requirements section of this
> element links to the Date-Time data type section already.
>
> * The Data Types subsections are now alphabetized, moving Character
> Data up to 3.1 and shifting the others accordingly.
>
> * For clarity, an RSS feed is always described as a feed. References
> to RSS document and RSS channel were changed.
>
> * When an element contains data described in a Data Types section,
the
> element's description now links to that data type.
>
> * In the Conventions section, two references that mistakenly called
> the profile a "specification" have been fixed.
>
> * Some references to the RSS 2.0 specification have been simplified.
>