Problems with <link> in a 0.91 RSS

[Francesco Moi]

Hello.

I'm trying to build a RSS feed for my website. It starts:

----------------//---------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"
"http://my.netscape.com/publish/formats/rss-0.91.dtd">
<rss version="0.91">
----------------//----------------------

And an item could be:
--------//--------------
<item>
<link>http://www.mydomain.com</link>
<title>Foo</title>
</item>
------//---------------

If instead of 'http://www.mydomain.com', I set
'http://www.mydomain.com/mypage.aspx?ID=1&cod=9&num=20031206'
I get problems of validation (some RSS readers do not read it).

Does exist any problem with these kind of URLs?

Thank you very much.

 

[Andy Dingley]

If instead of 'http://www.mydomain.com', I set
'http://www.mydomain.com/mypage.aspx?ID=1&cod=9&num=20031206'
I get problems of validation (some RSS readers do not read it).

Try this instead

http://www.mydomain.com/mypage.aspx?ID=1&amp;cod=9&amp;num=20031206


It's an XML entity issue, not RSS

 

[Bill Kearney]

To futher clarify, XML itself requires that a certain 5 characters should always
be entity encoded if used within an element or attribute value.

& - &amp;
< - &lt;

- &gt;

' - &apos;
" - &quot;

The one thing to guard against is double encoding. Do not re-encode n already
encoded entity. As in don't create &amp;amp;

This is less of an issue inside the link element than it is inside the
descriptions.

While many folks argue about this, the most commonly used and least distruptive
form is a single encoding of markup. For example, an HTML snippet of "this text
has both <b>bold</b> & <i>italic</i> text". The least harmful way to encode
this is "this text has both &lt;b&gt;bold&lt;/b&gt; &amp; &lt;i>italic&lt;/i&gt;
text". Sure, if the generating tool can /properly/ assure it's well-formed it's
perfectly reasonable to use XHTML instead. But most applications don't
consistently guarantee that their text will be valid, let alone well-formed. In
a perfect world it would be arguably superior to avoid using markup encoding.
Until that time arrives (don't hold your breath) using a single pass of encoding
has shown itself to be the most workable all-around.

-Bill Kearney
www.Syndic8.com - The worlds largest directory of RSS content

 

[Patrick TJ McPhee]

% To futher clarify, XML itself requires that a certain 5 characters should always
% be entity encoded if used within an element or attribute value.
%
% & - &amp;
% < - &lt;
% > - &gt;
% ' - &apos;
% " - &quot;

You waffle a bit there (requires ... should), but I'm going to disagree
anyway. Except when used in a CDATA section, & and < must always be
encoded. On the other hand, > never needs to be encoded. and ' and "
need be encoded only in attribute values, and only when they match the
value's delimiter. It is legal to encode any of the five outside a CDATA
section, but not always required.

My personal opinion is that you're better off using the predefined
entities as little as possible. It's hard to avoid using &amp;, but
I would always encode your example using a CDATA section

<![CDATA[this text has both <b>bold</b> & <i>italic</i> text]]>

 

[Andy Dingley]

The one thing to guard against is double encoding. Do not re-encode n already
encoded entity. As in don't create &amp;amp;

You often can't avoid this happening, especially not in an RSS-like
context where you're handling material that may already be encoded.

But if it does, make sure that your de-coding and en-coding is
balanced.

 

[Bill Kearney]

You often can't avoid this happening, especially not in an RSS-like
context where you're handling material that may already be encoded.

Then your code better work at improving the situation. Honestly, don't pass
along crap.

But if it does, make sure that your de-coding and en-coding is
balanced.

Sure, the trick lies in making sure the input is decoded properly and passed
along with the proper encoding as well.

It's not all that hard but it can be tedious to code properly.

-Bill Kearney

 

[Bill Kearney]

You waffle a bit there (requires ... should), but I'm going to disagree

anyway. Except when used in a CDATA section, & and < must always be
encoded. On the other hand, > never needs to be encoded. and ' and "
need be encoded only in attribute values, and only when they match the
value's delimiter. It is legal to encode any of the five outside a CDATA
section, but not always required.

Well, what's better, to worry about the if's and when's or to encode them
consistently?

My personal opinion is that you're better off using the predefined
entities as little as possible. It's hard to avoid using &amp;, but
I would always encode your example using a CDATA section

<![CDATA[this text has both <b>bold</b> & <i>italic</i> text]]>

Sure, provided tools understand how to use CDATA properly (many don't).

 

[Andy Dingley]

On Thu, 11 Dec 2003 11:28:46 -0500, "Bill Kearney"

[double encoding]

Then your code better work at improving the situation. Honestly, don't pass
along crap.

Rubbish. The _last_ thing your code should ever do is to try and "fix
up" content in transit. (Especially note the "in transit")

Multiple encoding is perfectly safe, and can be decoded perfectly by
applying the appropriate number of decodes. Where it goes wrong is
when someone breaks this number - encoding more than they should, or
less than they should. But I would _much_ rather receive the
occasional bit of extra-encoded garbage (it's semantically wrong, but
it's still well-formed XML) rather than run the risk of getting things
which have been "smart de-encoded" by something en-route that
"thought" it ought not to see an entity in that location and so
decided to decode the lot. That means it's no longer well-formed, and
that causes a lot of trouble down the line.

If you're _really_ worried about never rendering "&amp;" on screen for
the poor squeamish user, then do this in the user agent at the very
last point, when there's _no_ risk of it being propagated further.
This is also a good time to do it, as it's clearer (sic) here what the
content author's original intent was (maybe they're writing an RSS
feed of HTML coding tips and the entity is deliberate).

Are you really part of syndic8 ? Is this their official policy ?

 

[Patrick TJ McPhee]

% > You waffle a bit there (requires ... should), but I'm going to disagree
% > anyway. Except when used in a CDATA section, & and < must always be
% > encoded. On the other hand, > never needs to be encoded. and ' and "
% > need be encoded only in attribute values, and only when they match the
% > value's delimiter. It is legal to encode any of the five outside a CDATA
% > section, but not always required.
%
% Well, what's better, to worry about the if's and when's or to encode them
% consistently?

I guess, it depends on your goals. If you're writing what's `required',
I think it's better to be correct. If you have trouble keeping track
of when to use pre-defined entities, then you can take comfort in
the fact that it's always allowed, and not worry about when it's required.

% > My personal opinion is that you're better off using the predefined
% > entities as little as possible. It's hard to avoid using &amp;, but
% > I would always encode your example using a CDATA section
% >
% > <![CDATA[this text has both <b>bold</b> & <i>italic</i> text]]>
%
% Sure, provided tools understand how to use CDATA properly (many don't).

Well, why use these tools? What's the point of pretending to use XML if
you're really spending your life worrying about whether your tools can
support the basic syntax? It's fair enough to say that you'd prefer to
always use the predefined entities, but lack of CDATA support doesn't
merit consideration.

 

[Andy Dingley]

What's the point of pretending to use XML if
you're really spending your life worrying about whether your tools can
support the basic syntax?

We're dealing with RSS 0.91 here. The spec for the content here is
"ASCII", not even CDATA or PCDATA (Yes, Dave Winer's lousy
spec-writing).

If you do anything vaguely clever in the RSS field, it;'s likely to
break other people's (broken) code all over the place. It sucks, but
there you have it - your call.