Ach, late to the thread again.
When I saw Google Sitemaps I also thought of RDF Site Summary, and did
a sitemap2rss.xsl. But as noted already the role of RSS has mutated
from site summary to a content delivery format, so it wasn't a very
good fit. But it was straightforward to take their data
FYI. This can be addressed post-IESG evaluation.
-Scott-
-Original Message-
From: Mark Baker [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 16, 2005 11:07 AM
To: iesg@ietf.org
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RFC 2119 problem in Atom syndication format
Section
I'm not having much luck working
out how I can write (daily or there abouts)
an entry, without having to duplicate
feed metadata.
Am I alone in this?
Xinsert isn't common yet.. is it?
--
Regards,
Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk
http://www.dpawson.co.uk/blog/
I am preparing to write up some thoughts on an initial I-D for XML
Digital Signatures and Encryption in Atom and wanted to get some initial
thoughts from the group on a few syntax issues starting first with some
encryption thoughts:
Below are a few snippets of feeds with different
Dave Pawson,
I'm not having much luck working
out how I can write (daily or there abouts)
an entry, without having to duplicate
feed metadata.
I don't follow. Could you give an example showing the duplicated metadata?
--
Jimmy Cerra
https://nemo.dev.java.net
James M Snell wrote:
Thoughts?
The mot straightforward way (imo) to deal with encoded fragments is to
use two attributes, ie @type and @enc. So defining a new extension
attribute would work for me.
I'm not sure you need to deal with signalling the type of a fully
encrypted document in
On Thu, 2005-06-16 at 12:09 -0700, James Cerra wrote:
Dave Pawson,
I'm not having much luck working
out how I can write (daily or there abouts)
an entry, without having to duplicate
feed metadata.
I don't follow. Could you give an example showing the duplicated metadata?
Process.
Greetings again. Some people have started asking (mostly off-list)
when the Atom format would be done so they can implement and, more
importantly, deploy. This message gives our best shot at answering
the question.
The status of the format document is that the -09 draft is in the
IESG
Bill de hra wrote:
James M Snell wrote:
Thoughts?
The mot straightforward way (imo) to deal with encoded fragments is to
use two attributes, ie @type and @enc. So defining a new extension
attribute would work for me.
See my comments below on the type identification.
Here's another
Ok, question for the group.
Scenario: A content source is updated 100 times per hour. The Atom feed
currently only displays the 20 most recent entries. Users who are not
checking the feed every 10 minutes or so are missing entries. How do we
address this?
Solution: Rather than using a
Nice. I had pulled out of the Atom discussions to work on another
project back when this was being discussed and missed it.
Quick question tho.. in your initial post on the concept you state It
is my intention to create a Internet Draft describing the ideas here
once I've had reasonable
James M Snell wrote:
Nice. I had pulled out of the Atom discussions to work on another project
back when this was being discussed and missed it. Quick question tho.. in
your initial post on the concept you state It is my intention to create a
Internet Draft describing the ideas here
I do
I didn't see any requirement to encrypt feeds.
Please note my email re keyinfo and identification of signer from a few
weeks ago.
Hilarie Orman
13 matches
Mail list logo
