till now only one works. The plugins for Maxthon.
Others all do not work(update).  Maybe the clients do not think it has been updated as James said.

 
On 12/21/05, Bill Kearney <ml_yahoo@... > wrote:

Which client isn't working?

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

Thanks. I add guid and pubDate in my items, but most of RSS client also

still not work.

Yu Ting wrote:
>till now only one works. The plugins for Maxthon.
>Others all do not work(update).  Maybe the clients do not think it has been
>updated as James said.

Actually I'm beginning to think I might be wrong about the lack of support.
I just tested a couple of Windows clients and many of them worked. So far
FeedDemon (1.5) has been the only one I tested that definately doesn't work.
RSS Bandit, Sharpreader and BottomFeeder all got the updates and I know at
least one of them marked the updated item as unread. The other two I tried,
Blogbridge and Thunderbird wouldn't read the feed at all so I'm not sure
what their status is.

Regards
James

> > I only have 3 items in my rss2 scrips. I only want to change the
> > description in the items(title and others remine the same). But the
> > rss client can not recogize this item is updated. Do you have any
> > comments?

That won't work in all tools.   It should but there's a lot of bad tools out
there.

> I believe many RSS clients do not support updates. If they encounter an
item
> with a link, title and guid that they've seen before they will just ignore
> it thinking it's a duplicate. And clients that do support updating will
> quite probably only inform the user of the update if the pubDate is
changed
> too. Other updates will still be received, but the user won't know that
> there has been an update unless they check for themselves.

It's not that they don't support updates, it's more than "updates" have a
rather sordid history (which I won't go into here).  That and a great many
feeds STILL do not include proper timestamps on their items.  It's thus very
hard for the developer of a reader to come up with an effective rule on how
to handle items that change.  Start by changing the pubDate and test it in
the tools your audience is likely to be using.  If it doesn't work then,
well, you'll have to change the title each time.

-Bill Kearney
Syndic8.com

Which client isn't working?

----- Original Message -----
Thanks. I add guid and pubDate in my items, but most of RSS client also
still not work.

Yu Ting wrote:
> I only have 3 items in my rss2 scrips. I only want to change the
> description in the items(title and others remine the same). But the
> rss client can not recogize this item is updated. Do you have any
> comments?

I believe many RSS clients do not support updates. If they encounter an item
with a link, title and guid that they've seen before they will just ignore
it thinking it's a duplicate. And clients that do support updating will
quite probably only inform the user of the update if the pubDate is changed
too. Other updates will still be received, but the user won't know that
there has been an update unless they check for themselves.

Regards
James

Yu Ting wrote:

> How to let the client to update an exsiting news? There is a only
> little changed within the news.
> For example:
>
> I only have 3 items in my rss2 scrips. I only want to change the
> description in the items(title and others remine the same). But the
> rss client can not recogize this item is updated. Do you have any
> comments?

The items in a newsfeed should change, most noteable have different
content in the elements that clients use to determine if an item is new,
like the link and guid elements.

If your feed refers to a page that gets updated, you can still generate
unique addresses and guids, for example if your page is at
http://www.example.com/dailynews.html you can refer to items on that
page as http://www.example.com/dailynews.html#n1,
http://www.example.com/dailynews.html#n2, or
http://www.example.com/dailynews.html?n1 and
http://www.example.com/dailynews.html?n2 if you don't want to link to
specific items directly.

Any time you publish new news, that link gets updated (and old items
which are no longer relevant removed from the feed).

--
Klaus Johannes Rusch
KlausRusch@...
http://www.atmedia.net/KlausRusch/

The specification [1] is a bit confusing to me...

"The publication date for the content in the channel. For example, the New
York Times publishes on a daily basis, the publication date flips once every
24 hours. That's when the pubDate of the channel changes."

That example analogously implies the pubDate -- which is a channel element
-- should "flip" (change) each 24 hours. Is this correct? I thought the
pubDate was intended to represent a fixed point in time when the channel was
first published.

I also intend to use the RFC 822 date format as specified...
Sat, 07 Sep 2002 00:00:01 GMT

..but I've observed GMT as an acronym is now apparently deprecated in favor
of the acronym UTC which is expressed as "coordinated Universal Time" but is
only expressed in RFC 822 as a two-character designation, i.e. UT.

I would assume most readers are looking for the GMT acronym but wonder what
the general consensus on date representation may be for forward looking
development.

<%= Clinton Gallagher

[1] http://blogs.law.harvard.edu/tech/rss#optionalChannelElements

Lars wrote:
>> If this all sounds like a bit of a nightmare, well, there's
>> always Atom.
>
>I actually started with Atom, but gave up when I found that the "type"
>attribute on <title> is *never* a MIME type, while on <content> it
>*might* be a MIME type.

I'm not sure I understand your problem. If you want plain text you use the
"text" type. If you need html markup you can use the "html" type. If you'd
prefer to use unescaped xhtml for your markup then there's the "xhtml" type.
That's basically all you really need to know.

The support for MIME types in <content> elements is only for very rare
special cases that you're unlikely to need and I suspect very few
aggregators will support. One example would be an entry that is an embedded
PDF document.

For the vast majority of cases, all you need is plain text or (x)html and
Atom allows you to do that easily and clearly. There's no guessing involved.
There's no artificial intelligence required. I don't see how you could ask
for any better than that.

However, if you want to use RSS2 that's your choice to make. I tried to
provide guidelines in my previous message that would help you get the best
results possible given the limitations of the format, but there are no
guarantees.

Regards
James

--- In RSS2-Support@yahoogroups.com, "James Holderness"
<j4_james@h...> wrote:

> If this all sounds like a bit of a nightmare, well, there's
> always Atom.

I actually started with Atom, but gave up when I found that the "type"
attribute on <title> is *never* a MIME type, while on <content> it
*might* be a MIME type.  I'll admit that RSS 2.0 doesn't really
improve on this (thus my original question), but the spec made for
easier reading.

-- Lars

>The spec says that "entity-encoded HTML" is *allowed*, but doesn't say it's
>required.
>Furthermore, the spec doesn't provide for, e.g., a content-type attribute
>on the description
>element, so it's not clear to be how an RSS reader is supposed to handle
>the content.

Most RSS readers will assume that the content is always HTML since that's
the only sane thing they can do. There might be a certain amount of leniency
in the HTML interpretation (for example an unescaped ampersand that is
obviously not part of an entity will probably still display as an
ampersand), but that's about as good as it gets.

>I ask because I'm preparing to gate some local newsgroups to an RSS feed,
>and I'm unsure
>whether I should be converting the text to HTML (to preserve paragraphs,
>etc) or leaving it
>as-is.

If you want your content to be interpreted correctly by as many RSS readers
as possible, you should always convert the content of description elements
to HTML. There's really no question about it - that's just something that
you MUST do. When it comes to the title element, though, things aren't quite
so clear.

Although the spec doesn't say anything about HTML in title elements, you can
be fairly sure that there are some RSS readers that will treat titles as
HTML too. The safest thing would just be to avoid using ampersands or angle
brackets in a title. However if you really must have them, my recommendation
would be to escape once when free standing (i.e. surrounded by spaces)
otherwise escape twice.

If this all sounds like a bit of a nightmare, well, there's always Atom.

Regards
James

Hello all,

I've been reading through the RSS 2.0 spec, and unless I've missed something it
appears to
leave unspecified the type of data one is expected to put inside <item>'s
<description>
element.

The spec says that "entity-encoded HTML" is *allowed*, but doesn't say it's
required.
Furthermore, the spec doesn't provide for, e.g., a content-type attribute on the
description
element, so it's not clear to be how an RSS reader is supposed to handle the
content.

I ask because I'm preparing to gate some local newsgroups to an RSS feed, and
I'm unsure
whether I should be converting the text to HTML (to preserve paragraphs, etc) or
leaving it
as-is.  Some RSS readers (notably, Apple's Safari and RSSOwl) appear to always
treat the
<description> text as HTML.  Mostly I'm trying to figure out if this is required
by the
standard or if it's just happenstance.

Thanks,

   -- Lars

> Personally I would have thought a CDATA section the "least worst" way to
> transport markup, but I've often seen statements hinting that CDATA
sections
> are evil in some way (without actually going into detail why).

The main reason is they're a cop-out against actually grasping WHY encoding
is necessary.  Slapping a wrapper around it might seem useful but it only
deflects the problems down to another level.  And don't get me started on
the 'human-readable' nonsense.  People ain't ever reading these feeds with
the naked eye and well-written output code shouldn't even make it necessary
to read the results.  (he says having cheated many a time himself...)

> > But bear in mind that not everything will automagically understand the
> > entire range of HTML entities.  All of them, however, will understand
> > Unicode numeric entity references.  With the added bonus of not being
> > double-encoded.
>
> Very good point. I'm not in the business of producing feeds so I don't
often
> think about things from this point of view. Makes perfect sense though.

Yeah, it's all part of creating content that's "least harmful" by avoiding
short cuts.  When things are flattened down to numeric references and
consistently double-encoded, when needed, it helps avoid what I refer to the
'tyranny of bad tools'.  Where a well-known toolkit does a shitty job of a)
creating content or b) special-casing itself to work around bad habits.
Better to just make valid content and avoid the screwing around.  Thus why
the validator's so consistently picky about things.

Just because tool X can handle something doesn't make it valid.  That and
poorly written specs have done more to harm effective uptake (not to mention
wasting endless developer cycles..) than anything else.

-Bill Kearney
Syndic8.com

Bill Kearney wrote:
> That's certainly a possible assumption, just not one I read into it.  Your
> example of double-encoding is 'valid' in the sense that it safely isolates
> the HTML content from being parsed as part of the RSS XML.  It's the
> 'least
> worst' way to transport markup in RSS.

Personally I would have thought a CDATA section the "least worst" way to
transport markup, but I've often seen statements hinting that CDATA sections
are evil in some way (without actually going into detail why). They're
easier to read than double-encoding. They're more compact in all but the
simplest of cases. What's not to like about them?

> But bear in mind that not everything will automagically understand the
> entire range of HTML entities.  All of them, however, will understand
> Unicode numeric entity references.  With the added bonus of not being
> double-encoded.

Very good point. I'm not in the business of producing feeds so I don't often
think about things from this point of view. Makes perfect sense though.

Regards
James

> I believe he was refering to using HTML within a description element.

That's certainly a possible assumption, just not one I read into it.  Your
example of double-encoding is 'valid' in the sense that it safely isolates
the HTML content from being parsed as part of the RSS XML.  It's the 'least
worst' way to transport markup in RSS.

But bear in mind that not everything will automagically understand the
entire range of HTML entities.  All of them, however, will understand
Unicode numeric entity references.  With the added bonus of not being
double-encoded.

As to the use of unencoded ampersands in the link element, it's not valid.
When in doubt, run it through the validator.  While poorly-written specs
invite all sorts of guessing, the validator (the real one) doesn't.
http://feedvalidator.org

-Bill Kearney
Syndic8.com

Bill Kearney wrote:
>> You can have HTML content with no problems.  I display © ™
>> and other HTML functions with no problems.  I am using PHP primarily,
>> so what I do is convert this to RSS by using the htmlentities and
>> stripslashes functions when aggregating.
>
>Unless you specify a DTD you cannot use HTML entity encodings like
>©  You have to use the numeric ones.  While some reader programs
>might let this slide, many do not; because it's neither valid RSS nor XML.

I believe he was refering to using HTML within a description element. In
that case it's perfectly valid to include HTML entities as long as they're
escaped (basically double escaping). For example, there's nothing wrong with
a description like this:

<description>&amp;copy; Copyright 2005</description>

The only entity that XML sees is "&amp;" which is perfectly valid. Once that
"&amp;" is unescaped, the resulting content should be passed on to an HTML
renderer which shouldn't have any problem processing the "&copy;" entity.

From the RSS 2.0 documentation: "...the description contains the text
(entity-encoded HTML is allowed)..."

Regards
James

> You can have HTML content with no problems.  I display © ™
> and other HTML functions with no problems.  I am using PHP primarily,
> so what I do is convert this to RSS by using the htmlentities and
> stripslashes functions when aggregating.

Unless you specify a DTD you cannot use HTML entity encodings like
©  You have to use the numeric ones.  While some reader programs
might let this slide, many do not; because it's neither valid RSS nor XML.

-Bill Kearney
Syndic8.com

>I get the feeling that you aren't getting what I am saying.
>
>I'm not talking about links that exist inside content, I am talking
>about links that are between the <link> xyz </link> tags and the
><links> xyz </links> tags.

I'm fairly sure we're talking about the same thing, but I'll give you an
example of a valid section of RSS just to be clear:

<item>
   <pubDate>Sat, 22 Oct 2005 10:42:21 GMT</pubDate>
   <title>This is my title</title>
   <link>http://www.example.org/something.php?key1=value1&amp;key2=value2</link>
   <description>This is my description.</description>
</item>

Anything between the open <link> tag and the close </link> tag should be
escaped as shown above. From the XML spec:

'The ampersand character (&) and the left angle bracket (<) MUST NOT appear
in their literal form, except when used as markup delimiters, or within a
comment, a processing instruction, or a CDATA section. If they are needed
elsewhere, they MUST be escaped using either numeric character references or
the strings "&amp;" and "&lt;" respectively.'

>If I have a link there with &amp; it is not automatically converted by
>readers to &.

It definately should be. If you take an RSS feed containing links like that,
rename it to something.xml and open it up in Internet Explorer so that it is
viewed as XML, you should see those &amp; references automatically
unescaped. Conversely if you have an RSS feed that doesn't have ampersands
correctly escaped IE will flag it as invalid XML.

>If you are saying this is a reader/aggregator bug, let me know and
>I'll bring it up with them.  But as I've seen it in about 5 different
>readers, I was at the point of concluding that this is a specification
>issue.

Nope. This is definately a bug in those readers.

Regards
James

--- In RSS2-Support@yahoogroups.com, "James Holderness"
<j4_james@h...> wrote:
>
>
> >I don't have any problem with the data of content, only of the links
> >properties of the RSS <link> and <links> functions.
>
> An RSS feed is by definition an XML document. In the first few lines
of the
> RSS documentation it says: "RSS is dialect of XML. All RSS files must
> conform to the XML 1.0 specification, as published on the World Wide
Web
> Consortium (W3C) website."
>
> As such, the contents of a <link> element MUST be escaped as
described in
> section 2.4 of XML 1.0 (http://www.w3.org/TR/REC-xml/).
>
> I'm not sure what you meant by the <links> function - as far as I'm
aware
> there is no such element in RSS.
>
> >For example.  Let's say the article itself resides at:
> >http://www.yourdomain.com/modules.php?name=News&file=article&aricleid=1
> >
> >The proper formatting of that destination (in terms of W3C compliance)
> >would be:
>
>http://www.yourdomain.com/modules.php?name=News&amp;file=article&amp;articleid=\
1
>
> This is exactly how the link should be formatted if it was compliant
with
> the RSS documentation. If you are seeing something different in an
RSS feed
> then that's an error on the part of the feed producer. It's not the
fault of
> the RSS documentation.
>
> >Now, the problem with the RSS Specification is that the <link> and
> ><links> functions do not support these W3C Requirements.  If you use
> >&amp; instead of & in the properties of the link, the RSS
> >Readers/Aggregators will continue to propagate that &amp; value
> >(instead of automatically converting it to simply &, which is what
> >they SHOULD do).... Again, this is a specification problem, not an
> >aggregator or a RSS reader problem.
>
> Nope. This is certainly a bug in the RSS aggregator - which ones
have you
> been testing with? I know mine definately doesn't have this problem.
>
> >For information on the specification, see:
> >http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
> >and refer to section C-12.
>
> Yeah. That basically says exactly the same thing as the XML
documentation
> (http://www.w3.org/TR/REC-xml/). As I said, both RSS and Atom require
> compliance with the XML specs so anyone that's not doing that is doing
> something wrong. You should be complaining to the content producers
and/or
> the aggregator authors.
>
> Regards
> James
>


I get the feeling that you aren't getting what I am saying.

I'm not talking about links that exist inside content, I am talking
about links that are between the <link> xyz </link> tags and the
<links> xyz </links> tags.

As in
<item> blah </item>
<title> blah </title>
<link> xyz </link>

If I have a link there with &amp; it is not automatically converted by
readers to &.

This is demonstrated via Sage as well as other readers/aggregators.

If you are saying this is a reader/aggregator bug, let me know and
I'll bring it up with them.  But as I've seen it in about 5 different
readers, I was at the point of concluding that this is a specification
issue.

>I don't have any problem with the data of content, only of the links
>properties of the RSS <link> and <links> functions.

An RSS feed is by definition an XML document. In the first few lines of the
RSS documentation it says: "RSS is dialect of XML. All RSS files must
conform to the XML 1.0 specification, as published on the World Wide Web
Consortium (W3C) website."

As such, the contents of a <link> element MUST be escaped as described in
section 2.4 of XML 1.0 (http://www.w3.org/TR/REC-xml/).

I'm not sure what you meant by the <links> function - as far as I'm aware
there is no such element in RSS.

>For example.  Let's say the article itself resides at:
>http://www.yourdomain.com/modules.php?name=News&file=article&aricleid=1
>
>The proper formatting of that destination (in terms of W3C compliance)
>would be:
>http://www.yourdomain.com/modules.php?name=News&amp;file=article&amp;articleid=\
1

This is exactly how the link should be formatted if it was compliant with
the RSS documentation. If you are seeing something different in an RSS feed
then that's an error on the part of the feed producer. It's not the fault of
the RSS documentation.

>Now, the problem with the RSS Specification is that the <link> and
><links> functions do not support these W3C Requirements.  If you use
>&amp; instead of & in the properties of the link, the RSS
>Readers/Aggregators will continue to propagate that &amp; value
>(instead of automatically converting it to simply &, which is what
>they SHOULD do).... Again, this is a specification problem, not an
>aggregator or a RSS reader problem.

Nope. This is certainly a bug in the RSS aggregator - which ones have you
been testing with? I know mine definately doesn't have this problem.

>For information on the specification, see:
>http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
>and refer to section C-12.

Yeah. That basically says exactly the same thing as the XML documentation
(http://www.w3.org/TR/REC-xml/). As I said, both RSS and Atom require
compliance with the XML specs so anyone that's not doing that is doing
something wrong. You should be complaining to the content producers and/or
the aggregator authors.

Regards
James

--- In RSS2-Support@yahoogroups.com, "Clinton Gallagher"
<csgallagher@m...> wrote:
>
> > Message: 1
> >    Date: Sat, 15 Oct 2005 18:24:47 -0000
> >    From: "Steph" <boyinconcord@y...>
> > Subject: Direct Conflicts In Compliance Specifications - W3C
> >          Versus RSS/Atom/RDF
> >
> > Hi
> >
> > Take this with a grain of salt, but it strikes me as
> > oxymoronic that the various RSS/Atom specifications say
> > specifically that they are designed to comply with W3C
> > standards; however, the "link" and "links"
> > properties of all Atom/RDF/RSS/XML output standards fail to
> > conform to any of the sister W3C output formatting or
> > presentation standards.
> >
> > Specifically, in RSS/XML/ATOM/RDF formats there is a failure
> > to require that links be properly formatted with extended
> > values (&amp; for example), but rather these RSS standards
> > rely on the deprecated property of &.
>
> I couldn't agree with you more as I'm developing an application
> that will only allow specific HTML Character Entities; &amp;,
> &copy;, &trade;, and &reg; for example.
>
> I was about to send a kite asking for an RFI regardingg this
> context gut with regard to W3C standards you've answered my
> question saving me the hunt. You could provide the URL to
> the W3C standard in this regard if convenient.
>
> My focus is RSS 2.0 at the moment. Thus I'm asking what else
> you have learned with regard to the format of text entries
> such as the description element for example. Are you allowing
> HTML? To which extent. Is there a best practice document somewhere?
>
> <%= Clinton Gallagher
>

Hi Clinton

You can have HTML content with no problems.  I display &copy; &trade;
and other HTML functions with no problems.  I am using PHP primarily,
so what I do is convert this to RSS by using the htmlentities and
stripslashes functions when aggregating.

The only thing you can't do is use these W3C Specification functions
in the <link> and <links> functions of any of the RSS standards.
Everywhere else (pretty much) it is okay.

Hope this helps.
Steph

--- In RSS2-Support@yahoogroups.com, "James Holderness"
<j4_james@h...> wrote:
>
> >Specifically, in RSS/XML/ATOM/RDF formats there is a failure to
> >require that links be properly formatted with extended values (&amp;
> >for example), but rather these RSS standards rely on the deprecated
> >property of &.
>
> I'm not sure I'm following you. Can you show a specific example of
an Atom
> link element with this implemented incorrectly? Then show how it
should be
> represented if it was following the W3C presentation standards (I'm
also not
> exactly sure which standards you are referring to here).
>
> The only thing I could see in the spec about the formatting of
links was
> that an Atom document is required to be well formed XML in which case
> attributes containing ampersands (the link href in this case) must be
> escaped (i.e. & becomes &amp;). Since XML is a W3C standard I'm not
sure why
> you have a problem with that.
>
> Regards
> James
>
I don't have any problem with the data of content, only of the links
properties of the RSS <link> and <links> functions.

For example.  Let's say the article itself resides at:
http://www.yourdomain.com/modules.php?name=News&file=article&aricleid=1

The proper formatting of that destination (in terms of W3C compliance)
would be:
http://www.yourdomain.com/modules.php?name=News&amp;file=article&amp;articleid=1

Notice how amp; follows the ampersand symbol.  This is a W3C
REQUIREMENT (not an option, a requirement).  This makes the document
link compliant when displayed within either a news item OR when the
RSS page itself is viewed in reader (like Sage or other browser based
reader) or aggregator (like Magpie).

In this same regard, all links that appear within the content must
also be converted to this style (as they should be already on the
website in question in the article itself, not just in the RSS feed
data which is pulled from that article.)

In this situation, when using RSS aggregation or output software,
links always keep those W3C Compliant properties.

Now, the problem with the RSS Specification is that the <link> and
<links> functions do not support these W3C Requirements.  If you use
&amp; instead of & in the properties of the link, the RSS
Readers/Aggregators will continue to propagate that &amp; value
(instead of automatically converting it to simply &, which is what
they SHOULD do).... Again, this is a specification problem, not an
aggregator or a RSS reader problem.  If the specification of <link>
and <links> functions (of RSS) were converted to be actually W3C
Compliant, they would UNDERSTAND that the functions are actually
"Link" related functions and would thus convert the values dynamically
to simply & when followed.

If the specification was changed to support this W3C standard, RSS
output would not only be valid (which it actually is either way), but
would also be presentation compliant.

In the case where you have 10 articles with 2 ampersands in the link
to each article, you are in fact creating 20 W3C Non-Compliance
errors.  That's a problem that shouldn't exist, especially since
webmasters work so hard to achieve W3C Compliance in regular content.
  In this case, the link value is automatically pulled by my RSS
aggregation program, but I actually have to go in and physically code
a routine to "Break" W3C compliance in order for those links to
actually work.  That's bad.

For information on the specification, see:
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
and refer to section C-12.

If you still don't get it, I can give you example links that show the
compliance both ways and also that demonstrate that the links of
"Compliant" version don't work.

Steph

>Specifically, in RSS/XML/ATOM/RDF formats there is a failure to
>require that links be properly formatted with extended values (&
>for example), but rather these RSS standards rely on the deprecated
>property of &.

I'm not sure I'm following you. Can you show a specific example of an Atom
link element with this implemented incorrectly? Then show how it should be
represented if it was following the W3C presentation standards (I'm also not
exactly sure which standards you are referring to here).

The only thing I could see in the spec about the formatting of  links was
that an Atom document is required to be well formed XML in which case
attributes containing ampersands (the link href in this case) must be
escaped (i.e. & becomes &). Since XML is a W3C standard I'm not sure why
you have a problem with that.

Regards
James

> Message: 1
>    Date: Sat, 15 Oct 2005 18:24:47 -0000
>    From: "Steph" <boyinconcord@...>
> Subject: Direct Conflicts In Compliance Specifications - W3C
>          Versus RSS/Atom/RDF
>
> Hi
>
> Take this with a grain of salt, but it strikes me as
> oxymoronic that the various RSS/Atom specifications say
> specifically that they are designed to comply with W3C
> standards; however, the "link" and "links"
> properties of all Atom/RDF/RSS/XML output standards fail to
> conform to any of the sister W3C output formatting or
> presentation standards.
>
> Specifically, in RSS/XML/ATOM/RDF formats there is a failure
> to require that links be properly formatted with extended
> values (&amp; for example), but rather these RSS standards
> rely on the deprecated property of &.

I couldn't agree with you more as I'm developing an application
that will only allow specific HTML Character Entities; &amp;,
&copy;, &trade;, and &reg; for example.

I was about to send a kite asking for an RFI regardingg this
context gut with regard to W3C standards you've answered my
question saving me the hunt. You could provide the URL to
the W3C standard in this regard if convenient.

My focus is RSS 2.0 at the moment. Thus I'm asking what else
you have learned with regard to the format of text entries
such as the description element for example. Are you allowing
HTML? To which extent. Is there a best practice document somewhere?

<%= Clinton Gallagher

This is the link :
http://www.specialistdoctors.com/vlrss2.php

Heroes from 911 attack victims list on this
RSS feed. every time your page is visited, a
new person appears so their memories are kept
fresh always.

Very novel way to a memorial content.

They give iframe also for putting the content
on your page/site on this :
http://www.specialistdoctors.com/vlink.htm

Hi

Take this with a grain of salt, but it strikes me as oxymoronic that
the various RSS/Atom specifications say specifically that they are
designed to comply with W3C standards; however, the "link" and "links"
properties of all Atom/RDF/RSS/XML output standards fail to conform to
any of the sister W3C output formatting or presentation standards.

Specifically, in RSS/XML/ATOM/RDF formats there is a failure to
require that links be properly formatted with extended values (&
for example), but rather these RSS standards rely on the deprecated
property of &.

In doing so, while the link property is defined as "valid" (only for
RSS related functions and NOTHING else!) it fails to meet any
published W3C Presentation compliance requirements.

If you attempt to use extended property links in RSS, they of course
will be Valid in terms of the W3C as well as RSS Validation checkers;
however, they simply will not work as the RSS Readers and aggregators
cannot interpret nor convert them automatically to deprecated values,
unlike any other default browser or output interpreter functions.
Instead, they are returned with extended values and thus are invalid
destinations.

The problem with this scenario is that by default, many domains have
been specifically designed to conform with these important output
specifications and now special functions need to be created and
implemented to actually "undo" that work in order to create this
so-called, "valid" RSS output that will actually work (meaning, when
you click the link, you are taken to that destination).

The problem is especially visible when viewing that RSS output (in
terms of presentation compliance) in any RSS reader or browser as
presentation errors are created specifically because those same link
that need to be deprecated to function, are now non-compliant to the
published W3C Specifications that say that these link properties
cannot be deprecated, so you end up with X number of errors per page.

One would think that this single issue would be the easiest to fix in
terms of modifying the RSS specifications to comply and conform with
W3C Specifications, which would not only allow RSS to be truly Valid,
but also W3C Compliant in terms of presentation and function.

Just my two cents.
Steph Benoit, Developer
http://64bit.us

Hi

I am new to rss and have started using RSS for some of our hand
wrote information and reviews about all types of products.

These will be for others to use on there sites as content and good
information for users ( on http://www.webstoredirectory.co.uk )

I first used rss from a job site, I used there rss feed on my site
for jobs for my users.

I think rss is great.

My question is How and where can you submit your xml rss feeds for
people to find them?

Here is one of our feeds:

http://www.webstoredirectory.co.uk/rss/Digital-Cameras.xml

Thanks

Daniel

p.s any help would be great