Would it be pertinent to indicate how the enclosure actually functions since
its defining property is a URL which is an actionable element, e.g. some
aggregators download the enclosure when a person subscribes to the Web feed
and other aggregators simply link to the enclsoure where it may be
downloaded or launched by a media player when the link is clicked.
Are you saying we should add an attribute to enclosure to hint to the
aggregator whether the enclosure should be downloaded or simply linked
to?
Randy
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, "Clinton Gallagher"
<csgallagher@...> wrote:
>
> Would it be pertinent to indicate how the enclosure actually
functions since
> its defining property is a URL which is an actionable element, e.g.
some
> aggregators download the enclosure when a person subscribes to the
Web feed
> and other aggregators simply link to the enclsoure where it may be
> downloaded or launched by a media player when the link is clicked.
>
Roger Cadenhead fixed my subscription up (thank you) as I have asked the
following which I present again edited for clarity:
Would it be pertinent to indicate how the enclosure actually functions since
its defining property is a URL which is an actionable element? That is, some
aggregators download the enclosure when a person subscribes to the Web feed
and other aggregators simply link to the enclsoure where it may be
downloaded or launched by a media player when the link is clicked.
The RSS Advisory Board should consider further clarification in this context
which I would find helpful.
The purpose of an enclosure is defined in the original spec to be
prefetching, meaning downloading.
On Tue, May 13, 2008 at 11:42 AM, Clinton Gallagher
<csgallagher@...> wrote:
> Roger Cadenhead fixed my subscription up (thank you) as I have asked the
> following which I present again edited for clarity:
>
> Would it be pertinent to indicate how the enclosure actually functions since
> its defining property is a URL which is an actionable element? That is, some
> aggregators download the enclosure when a person subscribes to the Web feed
> and other aggregators simply link to the enclsoure where it may be
> downloaded or launched by a media player when the link is clicked.
>
>
> The RSS Advisory Board should consider further clarification in this context
> which I would find helpful.
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
Where in the original spec does it say this?
Thanks,
Randy
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, "Lucas Gonze" <lucas.gonze@...>
wrote:
>
> The purpose of an enclosure is defined in the original spec to be
> prefetching, meaning downloading.
>
>
The spec itself doesn't say that, but it links to a "use-case narrative"
that more or less says so (see http://www.thetwowayweb.com/payloadsforrss).
My interpretation is that an enclosure links to something that is probably
fairly large and that an RSS reader might potentially want to download in
advance. There's no requirement that an RSS reader MUST prefetch enclosures,
but it can definitely be advantageous to have that as an option.
Regards
James
Randy Morin wrote:
> Where in the original spec does it say this?
> Thanks,
>
> Randy
> http://www.therssweblog.com
>
> --- In rss-public@yahoogroups.com, "Lucas Gonze" <lucas.gonze@...>
> wrote:
>>
>> The purpose of an enclosure is defined in the original spec to be
>> prefetching, meaning downloading.
I think this is implementation details that can be determined by the
aggregator developers.
MHO,
Randy
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
wrote:
>
> The spec itself doesn't say that, but it links to a "use-case
narrative"
> that more or less says so (see
http://www.thetwowayweb.com/payloadsforrss).
>
> My interpretation is that an enclosure links to something that is
probably
> fairly large and that an RSS reader might potentially want to
download in
> advance. There's no requirement that an RSS reader MUST prefetch
enclosures,
> but it can definitely be advantageous to have that as an option.
>
> Regards
> James
>
The point to be made is that which suggests the pages which RSS Board
has published SHOULD BE modified to inform persons of that which we
know to be a fact; that is some aggregators will download the
enclosure when the feed is subscribed to and others may simply use
the URL to provide a link which may be used to load the enclosure in
a media player after subscription at some time later when the feed
may be read.
Doing so provides clear meaning to those turning to the work of the
board seeking clarification. Editing managers for example may have
knowledge of their markets which preclude the need to enclose
extraordinarily large files when a smaller file may be more useful
given that managing editors fully informed awareness of the
circumstances.
Secondly, I personally consider the link to Dave Winer's explanation
old, outdated and pragmatically useless not to mention its content
being written so long ago it is now inconsistent with contemporary
usage.
Are these comments sound?
<%= Clinton Gallagher
--- In rss-public@yahoogroups.com, "Randy Morin" <randy@...> wrote:
>
> I think this is implementation details that can be determined by
the
> aggregator developers.
> MHO,
>
> Randy
> http://www.therssweblog.com
>
> --- In rss-public@yahoogroups.com, "James Holderness" <j4_james@>
> wrote:
> >
> > The spec itself doesn't say that, but it links to a "use-case
> narrative"
> > that more or less says so (see
> http://www.thetwowayweb.com/payloadsforrss).
> >
> > My interpretation is that an enclosure links to something that is
> probably
> > fairly large and that an RSS reader might potentially want to
> download in
> > advance. There's no requirement that an RSS reader MUST prefetch
> enclosures,
> > but it can definitely be advantageous to have that as an option.
> >
> > Regards
> > James
> >
>
I think this is not a bad idea.
I'm a video podcaster. Currently I run two seperate feeds
1) podcast: m4v for ipod
2) update: text + .ram (realvideo metafile)
precisely to work around this problem
I tried using the MRSS alternative feed syntax in the early days but it didn't
seem to work well
or have much adoption so I dropped it.
Joly MacFie
http://punkcast.com
At 09:48 2008-05-13, you wrote:
>Are you saying we should add an attribute to enclosure to hint to the
>aggregator whether the enclosure should be downloaded or simply linked
>to?
>
>Randy
>http://www.therssweblog.com
>
>--- In rss-public@yahoogroups.com, "Clinton Gallagher"
><csgallagher@...> wrote:
>>
>> Would it be pertinent to indicate how the enclosure actually
>functions since
>> its defining property is a URL which is an actionable element, e.g.
>some
>> aggregators download the enclosure when a person subscribes to the
>Web feed
>> and other aggregators simply link to the enclsoure where it may be
>> downloaded or launched by a media player when the link is clicked.
>>
>
>
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>
---------------------------------------------------------------
WWWhatsup NYC
http://pinstand.com - http://punkcast.com
---------------------------------------------------------------
Joly,
I don't understand the problem. Can somebody write blog entry that
describes the problem with sample RSS showing the problem and the
solution?
Thanks,
Randy
http://www.therssweblog.com
Related: Does anybody have an update on MRSS namespace issue? Is
Yahoo! ignoring the problem?
--- In rss-public@yahoogroups.com, WWWhatsup <joly@...> wrote:
>
> I think this is not a bad idea.
>
> I'm a video podcaster. Currently I run two seperate feeds
> 1) podcast: m4v for ipod
> 2) update: text + .ram (realvideo metafile)
>
> precisely to work around this problem
>
> I tried using the MRSS alternative feed syntax in the early days
but it didn't seem to work well
> or have much adoption so I dropped it.
>
> Joly MacFie
> http://punkcast.com
>
>
>
Yahoo! fixed the namespace issue in Media RSS 1.1.2.
It was also decided that the RSS Advisory Board would take over the
management of Media RSS because Yahoo! had done such a lousy job. I've
not heard about any progress on that front.
--
Ryan Parman
<http://ryanparman.com>
On May 24, 2008, at 8:05 AM, Randy Morin wrote:
> Joly,
> I don't understand the problem. Can somebody write blog entry that
> describes the problem with sample RSS showing the problem and the
> solution?
> Thanks,
>
> Randy
> http://www.therssweblog.com
>
> Related: Does anybody have an update on MRSS namespace issue? Is
> Yahoo! ignoring the problem?
>
> --- In rss-public@yahoogroups.com, WWWhatsup <joly@...> wrote:
> >
> > I think this is not a bad idea.
> >
> > I'm a video podcaster. Currently I run two seperate feeds
> > 1) podcast: m4v for ipod
> > 2) update: text + .ram (realvideo metafile)
> >
> > precisely to work around this problem
> >
> > I tried using the MRSS alternative feed syntax in the early days
> but it didn't seem to work well
> > or have much adoption so I dropped it.
> >
> > Joly MacFie
> > http://punkcast.com
> >
> >
> >
>
>
>
[Non-text portions of this message have been removed]
--- In rss-public@yahoogroups.com, Ryan Parman
<ryan.lists.warpshare@...> wrote:
> It was also decided that the RSS Advisory Board would take over the
> management of Media RSS because Yahoo! had done such a lousy job.
> I've not heard about any progress on that front.
After the holiday, I will check with Yahoo to see the status of this
move. We're definitely interested in taking over management of the
spec and bringing on some board members with MediaRSS and podcasting
expertise.
The problem would be that there is no way within rss to give
people multiple media choices within one feed
One just makes a different feed.
Like, in my case, 1) 'podcast' is the the heavy footprint push, while 2)
'update' is the light
footprint pull.
In the latter the enclosure being a metafile.
I use realmedia because one can use a metafile that still utilizes http to
deliver the file.
A quicktime 'reference movie' would require a quicktime server.
But most people subscribe to the podcast.
Recently I have been shooting more jazz, a lot of which is longform as agaonst
the 5 minute songs that comprise most of my material. I've not been including
them in the podcast
because I don't want to dump an unexpected couple of 100MB on the unsuspecting
subscribers -
that would be a n example. Obviously discrimination based on size could be built
into a reader, but
another solution would be if publishers could classify enclosures, e.g.
essential, non-essential, short form, long-form,
opt-in etc, even via their own mini-schemas, that would control what actually
gets grabbed by readers.
joly
At 11:05 2008-05-24, you wrote:
>Joly,
>I don't understand the problem. Can somebody write blog entry that
>describes the problem with sample RSS showing the problem and the
>solution?
>Thanks,
>
>Randy
>http://www.therssweblog.com
>
>Related: Does anybody have an update on MRSS namespace issue? Is
>Yahoo! ignoring the problem?
>
>--- In rss-public@yahoogroups.com, WWWhatsup <joly@...> wrote:
>>
>> I think this is not a bad idea.
>>
>> I'm a video podcaster. Currently I run two seperate feeds
>> 1) podcast: m4v for ipod
>> 2) update: text + .ram (realvideo metafile)
>>
>> precisely to work around this problem
>>
>> I tried using the MRSS alternative feed syntax in the early days
>but it didn't seem to work well
>> or have much adoption so I dropped it.
>>
>> Joly MacFie
>> http://punkcast.com
>>
>>
>>
>
>
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>
---------------------------------------------------------------
WWWhatsup NYC
http://pinstand.com - http://punkcast.com
---------------------------------------------------------------
You could use SMIL in Quicktime to do the metafile. That's probably
worthwhile because the Real installed base is so low now. But then
again, you could also have a Flash embed in the description and it
would work out the same way.
On Sun, May 25, 2008 at 4:29 AM, WWWhatsup <joly@...> wrote:
>
> The problem would be that there is no way within rss to give
> people multiple media choices within one feed
>
> One just makes a different feed.
>
> Like, in my case, 1) 'podcast' is the the heavy footprint push, while 2)
'update' is the light
> footprint pull.
>
> In the latter the enclosure being a metafile.
>
> I use realmedia because one can use a metafile that still utilizes http to
deliver the file.
> A quicktime 'reference movie' would require a quicktime server.
>
> But most people subscribe to the podcast.
>
> Recently I have been shooting more jazz, a lot of which is longform as agaonst
> the 5 minute songs that comprise most of my material. I've not been including
them in the podcast
> because I don't want to dump an unexpected couple of 100MB on the
unsuspecting subscribers -
> that would be a n example. Obviously discrimination based on size could be
built into a reader, but
> another solution would be if publishers could classify enclosures, e.g.
essential, non-essential, short form, long-form,
> opt-in etc, even via their own mini-schemas, that would control what actually
gets grabbed by readers.
>
> joly
>
>
> At 11:05 2008-05-24, you wrote:
>>Joly,
>>I don't understand the problem. Can somebody write blog entry that
>>describes the problem with sample RSS showing the problem and the
>>solution?
>>Thanks,
>>
>>Randy
>>http://www.therssweblog.com
>>
>>Related: Does anybody have an update on MRSS namespace issue? Is
>>Yahoo! ignoring the problem?
>>
>>--- In rss-public@yahoogroups.com, WWWhatsup <joly@...> wrote:
>>>
>>> I think this is not a bad idea.
>>>
>>> I'm a video podcaster. Currently I run two seperate feeds
>>> 1) podcast: m4v for ipod
>>> 2) update: text + .ram (realvideo metafile)
>>>
>>> precisely to work around this problem
>>>
>>> I tried using the MRSS alternative feed syntax in the early days
>>but it didn't seem to work well
>>> or have much adoption so I dropped it.
>>>
>>> Joly MacFie
>>> http://punkcast.com
>>>
>>>
>>>
>>
>>
>>
>>------------------------------------
>>
>>Yahoo! Groups Links
>>
>>
>>
> ---------------------------------------------------------------
> WWWhatsup NYC
> http://pinstand.com - http://punkcast.com
> ---------------------------------------------------------------
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
By the way, this goes to the general issue of what the point of the
enclosure element is. It's convenient for pre-fetching for offline
use in a portable device. But in an online context HTML is a lot more
sensible.
On Sun, May 25, 2008 at 10:35 AM, Lucas Gonze <lucas.gonze@...> wrote:
> You could use SMIL in Quicktime to do the metafile. That's probably
> worthwhile because the Real installed base is so low now. But then
> again, you could also have a Flash embed in the description and it
> would work out the same way.
>
>
>
> On Sun, May 25, 2008 at 4:29 AM, WWWhatsup <joly@...> wrote:
>>
>> The problem would be that there is no way within rss to give
>> people multiple media choices within one feed
>>
>> One just makes a different feed.
>>
>> Like, in my case, 1) 'podcast' is the the heavy footprint push, while 2)
'update' is the light
>> footprint pull.
>>
>> In the latter the enclosure being a metafile.
>>
>> I use realmedia because one can use a metafile that still utilizes http to
deliver the file.
>> A quicktime 'reference movie' would require a quicktime server.
>>
>> But most people subscribe to the podcast.
>>
>> Recently I have been shooting more jazz, a lot of which is longform as
agaonst
>> the 5 minute songs that comprise most of my material. I've not been including
them in the podcast
>> because I don't want to dump an unexpected couple of 100MB on the
unsuspecting subscribers -
>> that would be a n example. Obviously discrimination based on size could be
built into a reader, but
>> another solution would be if publishers could classify enclosures, e.g.
essential, non-essential, short form, long-form,
>> opt-in etc, even via their own mini-schemas, that would control what actually
gets grabbed by readers.
>>
>> joly
>>
>>
>> At 11:05 2008-05-24, you wrote:
>>>Joly,
>>>I don't understand the problem. Can somebody write blog entry that
>>>describes the problem with sample RSS showing the problem and the
>>>solution?
>>>Thanks,
>>>
>>>Randy
>>>http://www.therssweblog.com
>>>
>>>Related: Does anybody have an update on MRSS namespace issue? Is
>>>Yahoo! ignoring the problem?
>>>
>>>--- In rss-public@yahoogroups.com, WWWhatsup <joly@...> wrote:
>>>>
>>>> I think this is not a bad idea.
>>>>
>>>> I'm a video podcaster. Currently I run two seperate feeds
>>>> 1) podcast: m4v for ipod
>>>> 2) update: text + .ram (realvideo metafile)
>>>>
>>>> precisely to work around this problem
>>>>
>>>> I tried using the MRSS alternative feed syntax in the early days
>>>but it didn't seem to work well
>>>> or have much adoption so I dropped it.
>>>>
>>>> Joly MacFie
>>>> http://punkcast.com
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>------------------------------------
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>> ---------------------------------------------------------------
>> WWWhatsup NYC
>> http://pinstand.com - http://punkcast.com
>> ---------------------------------------------------------------
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>
Hi,
In message 1720 I asked/complained about the handling of language tags
in RSS 2.0 best practices and specification. The links provided (to
W3C, Netscape, Library of Congress) are outdated and no mention is
made of the actual standard used to define these language values (IETF
BCP 47, RFC 4646).
In addition, on the URI list (uri@...), there is some question
about whether URLs in RSS correspond to the definition in XML (that
is, something called a "legacy encoded IRI") or to "pure" URIs. This
is important as it relates to how non-ASCII domain names and path
values are handled.
Best Regards,
Addison Phillips
Globalization Architect, Lab126
Chair, W3C Internationalization Core WG
--- In rss-public@yahoogroups.com, "Addison Phillips" <addison@...> wrote:
> In browsing the Best Practices profile [1], I note that the
> definition of language in RSS is a bit stale. In particular, the
> profile implies that only ISO 639 codes are valid and the link to
> RSS 0.91 codes is slightly stale also.
The profile's definition is based on the RSS 2.0 spec's guidance for
allowable language codes, which is this: "A list of allowable values
for this element, as provided by Netscape, is here [1]. You may also
use values defined [2] by the W3C."
1: http://www.rssboard.org/rss-language-codes
2: http://www.w3.org/TR/REC-html40/struct/dirlang.html#langcodes
> In fact, the language tags defined by W3C are the same as IETF BCP 47
> (currently represented by RFC 4646) and the codes, including the ISO
> 639 codes, are all included in an IANA maintained subtag registry. I
> would like to suggest updating the Best Practices profile and other
> documentation to reflect these changes.
Where would you like the spec and profile to link? I'd like to see us
offer the best advice here, and we're in a good position to help
because we get a lot of traffic for people searching for "RSS language
codes":
http://www.google.com/search?q=rss+language+codes
Addison Phillips wrote:
>
> Hi,
>
> In message 1720 I asked/complained about the handling of language tags
> in RSS 2.0 best practices and specification. The links provided (to
> W3C, Netscape, Library of Congress) are outdated and no mention is
> made of the actual standard used to define these language values (IETF
> BCP 47, RFC 4646).
The feed validator uses the following:
http://feedvalidator.org/docs/error/InvalidLanguage.html
> In addition, on the URI list (uri@... <mailto:uri%40w3.org>), there
> is some question
> about whether URLs in RSS correspond to the definition in XML (that
> is, something called a "legacy encoded IRI") or to "pure" URIs. This
> is important as it relates to how non-ASCII domain names and path
> values are handled.
Link to the discussion:
http://lists.w3.org/Archives/Public/uri/2008Jun/0117.html
> Best Regards,
>
> Addison Phillips
> Globalization Architect, Lab126
> Chair, W3C Internationalization Core WG
- Sam Ruby
When I try to get feedburner to identify my feed:
http://lovejanice.com/blog/feed/
I get this problem:
The feed address you entered includes an invalid leading or trailing character
in the
hostname. FeedBurner cannot resolve an address with leading or trailing
punctuation. Try
providing your feed's unique IP address to avoid this problem.
So, I tried validating my feed with W3.org and I get these problems... please
help!
Sorry
This feed does not validate.
line 1, column 1: Blank line before XML declaration [help]
^
In addition, interoperability with the widest range of feed readers could be
improved by
implementing the following recommendations.
line 12, column 102: Self reference doesn't match document location [help]
... rel="self" type="application/rss+xml" />
^
line 36, column 0: description should not contain script tag (4 occurrences)
[help]
<description><![CDATA[<div style="float: right; width: 42px; padding-right ...
line 51, column 0: content:encoded should not contain script tag (4 occurrences)
[help]
<content:encoded><![CDATA[<div style="float: right; width: 42px; padding-
...
line 97, column 28: guid should not be blank [help]
<guid isPermaLink="false"></guid>
^
Source: http://lovejanice.com/blog/feed/
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
>
<channel>
<title>Love Janice</title>
<atom:link href="http://lovejanice.com/blog/index.php/feed/" rel="self"
type="application/rss+xml" />
<link>http://lovejanice.com/blog</link>
<description>The Official Site & Blog of Janice Dickinson - the World's
First
Supermodel.</description>
<pubDate>Wed, 13 Aug 2008 00:18:38 +0000</pubDate>
<generator>http://wordpress.org/?v=2.6</generator>
<language>en</language>
<item>
<title>A Quick Trip To Rite Aid and 5 Tips To look Younger</title>
<link>http://lovejanice.com/blog/2008/08/12/quicktriptoriteaid/</link>
<comments>http://lovejanice.com/blog/2008/08/12/quicktriptoriteaid/#comments</co
mments>
<pubDate>Tue, 12 Aug 2008 16:42:48 +0000</pubDate>
<dc:creator>Janice Dickinson</dc:creator>
<category><![CDATA[Beauty]]></category>
<category><![CDATA[Janice's Top List]]></category>
<category><![CDATA[Make-up]]></category>
<category><![CDATA[Aging]]></category>
<category><![CDATA[Tips]]></category>
<guid isPermaLink="false">http://lovejanice.com/blog/?p=28</guid>
<description><![CDATA[<div style="float: right; width: 42px; padding-right:
10px;
margin: 0 0 0 10px;"><script type="text/javascript">
<!--
digg_url = 'http://lovejanice.com/blog/2008/08/12/quicktriptoriteaid/';
digg_bgcolor = '';
digg_skin = '';
digg_window = '';
digg_title = 'A Quick Trip To Rite Aid and 5 Tips To look Younger';
digg_bodytext = '';
digg_media = '';
digg_topic = '';
//-->
</script>
<script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script>
</div>
Well I know it may sound a bit shocking, but I actually do go shopping at
Rite Aid as
often as I can. What can I say, I love a good pharmacy shopping spree.
It’s like a
product bananza in there. I am often am asked about the products I
[...]]]></description>
<content:encoded><![CDATA[<div style="float: right; width: 42px;
padding-right:
10px; margin: 0 0 0 10px;"><script type="text/javascript">
The problem with FeedBurner and the validator seem to be unrelated. I
suggest reposting in the FeedBurner help forum as well.
http://groups.google.com/group/feedburner
The biggest problem I recognize is the validator error, where you
have leading whitespace before the XML decl. I believe you can fix
this by editing your Wordpress RSS feed template and removing the
leading white manually. All the spaces and line breaks before the <?
xml.
Having a blank GUID can also be problematic. You may want to replace
your current feed template with one of the defaults.
Hope this helps,
Randy
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, "Blake Burdette" <burdette82@...>
wrote:
>
> When I try to get feedburner to identify my feed:
>
> http://lovejanice.com/blog/feed/
>
> I get this problem:
>
> The feed address you entered includes an invalid leading or
trailing character in the
> hostname. FeedBurner cannot resolve an address with leading or
trailing punctuation. Try
> providing your feed's unique IP address to avoid this problem.
>
> So, I tried validating my feed with W3.org and I get these
problems... please help!
>
> Sorry
>
> This feed does not validate.
> line 1, column 1: Blank line before XML declaration [help]
>
> ^
> In addition, interoperability with the widest range of feed readers
could be improved by
> implementing the following recommendations.
> line 12, column 102: Self reference doesn't match document location
[help]
> ... rel="self" type="application/rss+xml" />
> ^
> line 36, column 0: description should not contain script tag (4
occurrences) [help]
> <description><![CDATA[<div style="float: right;
width: 42px; padding-right ...
> line 51, column 0: content:encoded should not contain script tag (4
occurrences) [help]
> <content:encoded><![CDATA[<div style="float:
right; width: 42px; padding-
> ...
> line 97, column 28: guid should not be blank [help]
> <guid isPermaLink="false"></guid>
> ^
> Source: http://lovejanice.com/blog/feed/
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rss version="2.0"
> xmlns:content="http://purl.org/rss/1.0/modules/content/"
> xmlns:wfw="http://wellformedweb.org/CommentAPI/"
> xmlns:dc="http://purl.org/dc/elements/1.1/"
> xmlns:atom="http://www.w3.org/2005/Atom"
> >
>
> <channel>
> <title>Love Janice</title>
> <atom:link href="http://lovejanice.com/blog/index.php/feed/"
rel="self"
> type="application/rss+xml" />
> <link>http://lovejanice.com/blog</link>
> <description>The Official Site & Blog of Janice
Dickinson - the World's First
> Supermodel.</description>
> <pubDate>Wed, 13 Aug 2008 00:18:38 +0000</pubDate>
> <generator>http://wordpress.org/?v=2.6</generator>
> <language>en</language>
> <item>
> <title>A Quick Trip To Rite Aid and 5 Tips To look
Younger</title>
>
<link>http://lovejanice.com/blog/2008/08/12/quicktriptoriteaid/</link>
>
<comments>http://lovejanice.com/blog/2008/08/12/quicktriptoriteaid/#co
mments</co
> mments>
> <pubDate>Tue, 12 Aug 2008 16:42:48 +0000</pubDate>
> <dc:creator>Janice Dickinson</dc:creator>
> <category><![CDATA[Beauty]]></category>
>
> <category><![CDATA[Janice's Top List]]></category>
>
> <category><![CDATA[Make-up]]></category>
>
> <category><![CDATA[Aging]]></category>
>
> <category><![CDATA[Tips]]></category>
>
> <guid isPermaLink="false">http://lovejanice.com/blog/?
p=28</guid>
> <description><![CDATA[<div style="float: right; width: 42px;
padding-right: 10px;
> margin: 0 0 0 10px;"><script type="text/javascript">
> <!--
> digg_url
= 'http://lovejanice.com/blog/2008/08/12/quicktriptoriteaid/';
> digg_bgcolor = '';
> digg_skin = '';
> digg_window = '';
> digg_title = 'A Quick Trip To Rite Aid and 5 Tips To look Younger';
> digg_bodytext = '';
> digg_media = '';
> digg_topic = '';
> //-->
> </script>
> <script src="http://digg.com/tools/diggthis.js"
type="text/javascript"></script>
> </div>
> Well I know it may sound a bit shocking, but I actually do go
shopping at Rite Aid as
> often as I can. What can I say, I love a good pharmacy shopping
spree. It’s like a
> product bananza in there. I am often am asked about the products I
[...]]]></description>
> <content:encoded><
Send Email
