On 8/26/05, Graham [EMAIL PROTECTED] wrote:
(And before you say but my aggregator is nothing but a podcast
client, and the feeds are nothing but links to enclosures, so it's
obvious that the publisher wanted me to download them -- WRONG! The
publisher might want that, or they might not
On Monday, August 29, 2005, at 10:12 AM, Mark Pilgrim wrote:
On 8/26/05, Graham [EMAIL PROTECTED] wrote:
(And before you say but my aggregator is nothing but a podcast
client, and the feeds are nothing but links to enclosures, so it's
obvious that the publisher wanted me to download them --
On Monday, August 29, 2005, at 10:39 AM, Antone Roundy wrote:
ext:auto-download target=enclosures default=false /
More robust would be:
ext:auto-download target=[EMAIL PROTECTED]'enclosure'] default=false
/
...enabling extension elements to be named in @target without
* Antone Roundy [EMAIL PROTECTED] [2005-08-29 19:00]:
More robust would be:
ext:auto-download target=[EMAIL PROTECTED]'enclosure']
default=false /
...enabling extension elements to be named in @target without
requiring a list of @target values to be maintained anywhere.
Is it wise to
--On Monday, August 29, 2005 10:39:33 AM -0600 Antone Roundy [EMAIL
PROTECTED] wrote:
As has been suggested, to inline images, we need to add frame documents,
stylesheets, Java applets, external JavaScript code, objects such as Flash
files, etc., etc., etc. The question is, with respect to
* Mark Pilgrim [EMAIL PROTECTED] [2005-08-29 18:20]:
On 8/26/05, Graham [EMAIL PROTECTED] wrote:
So you're saying browsers should check robots.txt before
downloading images?
It's sad that such an inane dodge would even garner any
attention at all, much less require a response.
I’m with
Le 05-08-26 à 18:59, Bob Wyman a écrit :
Karl, Please, accept my apologies for this. I could have sworn we
had the policy prominently displayed on the site. I know we used to
have it
there. This must have been lost when we did a site redesign last
November!
I'm really surprised that it
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=no /
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=yes /
content src=http://www.example.com/enclosure.mp3; x:follow=no /
content src=http://www.example.com/enclosure.mp3; x:follow=yes /
???
-
On 30/8/05 11:19 AM, James M Snell [EMAIL PROTECTED] wrote:
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=no /
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=yes /
content src=http://www.example.com/enclosure.mp3; x:follow=no /
content
Eric Scheid wrote:
On 30/8/05 11:19 AM, James M Snell [EMAIL PROTECTED] wrote:
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=no /
link rel=enclosure href=http://www.example.com/enclosure.mp3;
x:follow=yes /
content src=http://www.example.com/enclosure.mp3;
On 30/8/05 12:05 PM, James M Snell [EMAIL PROTECTED] wrote:
That's kinda where I was going with x:follow=no|yes. An
x:archive=no|yes would also make some sense but could also be handled
with HTTP caching (e.g. set the referenced content to expire
immediately). x:index=no|yes doesn't seem
--On August 30, 2005 11:39:04 AM +1000 Eric Scheid [EMAIL PROTECTED] wrote:
Someone wrote up A Robots Processing Instruction for XML Documents
http://atrus.org/writings/technical/robots_pi/spec-199912__/
That's a PI though, and I have no idea how well supported they are. I'd
prefer a
--On August 29, 2005 7:05:09 PM -0700 James M Snell [EMAIL PROTECTED] wrote:
x:index=no|yes doesn't seem to make a lot of sense in this case.
It makes just as much sense as it does for HTML files. Maybe it is a
whole group of Atom test cases. Maybe it is a feed of reboot times
for the server.
On 8/29/05, Walter Underwood [EMAIL PROTECTED] wrote:
That was me. I think it makes perfect sense as a PI. But I think reuse
via namespaces is oversold. For example, we didn't even try to use
Dublin Core tags in Atom.
Speak for yourself :)
http://bitworking.org/news/Not_Invented_Here
Walter Underwood wrote:
--On August 30, 2005 11:39:04 AM +1000 Eric Scheid [EMAIL PROTECTED] wrote:
Someone wrote up A Robots Processing Instruction for XML Documents
http://atrus.org/writings/technical/robots_pi/spec-199912__/
That's a PI though, and I have no idea how well supported
Im sorry, but I cant
go on without complaining. Microsoft has proposed extensions which turn
RSS V2.0 feeds into lists and weve got folk who are proposing much the
same for Atom (i.e. stateful, incremental or partitioned feeds) I think
they are wrong. Feeds arent lists and Lists arent
16 matches
Mail list logo
