On 28/1/05 7:39 AM, Henri Sivonen [EMAIL PROTECTED] wrote:
If the value of type is XHTML, the content of the Text construct
MUST be a single xhtml:div element
-1 gratuitous element cruft. The text construct element itself serves
as a container.
but atom:title != xhtml:title
also, are
On 28/1/05 10:02 AM, Eric Scheid [EMAIL PROTECTED] wrote:
I used a Link construct to keep word count down
and now with -05 published there is no generic Link Construct. I'll update
the pace with all the necessary extra wordage and bloat.
e.
On 28/1/05 4:58 PM, Henri Sivonen [EMAIL PROTECTED] wrote:
a:copyright type='XHTML'Copyright 2005 John Doe, h:emall rights
reserved/h:em/a:copyright
(assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML
namespace) is less crufty than
a:copyright type='XHTML'div
On 27/1/05 7:47 AM, Sjoerd Visscher [EMAIL PROTECTED] wrote:
The whole point of xml:base is that an application that stores a page
outside of its original context can add an xml:base to prevent losing
the original location context.
browsers don't.
all they know is here is a URL to a
On 27/1/05 9:24 AM, Henri Sivonen [EMAIL PROTECTED] wrote:
Sorry, I don't understand what your example is demonstrating.
How would the above be different from:
title
type='XHTML'Iamp;nbsp;doamp;nbsp;notamp;nbsp;likeamp;nbsp;lt;
marquee/title
title type='XHTML'Ido not like
On 27/1/05 3:38 PM, Sam Ruby [EMAIL PROTECTED] wrote:
atom:@rel doesn't allow for multiple space delimited values.
e.
http://lists.w3.org/Archives/Public/www-html/2003Jun/0133.html
agreed, a single term @rel value is preferred.
the shortcut icon thing is borked ... the linked favicon is
On 26/1/05 2:16 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
I like the proposal in general though I wonder why an absolute URI is
required.
One of the intended uses is for when a browser downloads a feed resource to
disk, and then hands that file to an atom handler application. Once that
On 26/1/05 8:58 AM, Walter Underwood [EMAIL PROTECTED] wrote:
An external transport protocol (e.g. HTTP with text/xml content-type)
may force the document to be decoded as US-ASCII. In that case ...
+1
e.
On 26/1/05 4:44 AM, Tim Bray [EMAIL PROTECTED] wrote:
Agreed. Then the only comment that remains is:
# Also, could an additional requirement be added. Namely that
# aggregators use the URI in |rel=self| to check for the feed next
# time?
-1
If I got the feed from location X, I may
On 26/1/05 11:50 AM, Martin Duerst [EMAIL PROTECTED] wrote:
A relative URI would only be useful if there is in fact an xml:base in
effect. With no xml:base then the relative reference would be useless.
That's pretty obvious, and applies to all other links. If we want to
point that out in
On 26/1/05 2:49 PM, Robert Sayre [EMAIL PROTECTED] wrote:
[3.1.1 says TYPE is one thing]
[3.5.2 says TYPE is the opposite]
Ah, you're right. Still don't see how it's vague, though.
It's only clear what's going on when the reader juxtaposes the two sections,
and realises that the concept
On 25/1/05 12:33 PM, Graham [EMAIL PROTECTED] wrote:
BUT, making the updated date optional is something I support. Anyone
else?
I originally thought so, but was willing to bend to the will of the
developers that didn't like having an element that may or may not be there
and thus required some
On 25/1/05 11:17 AM, Tim Bray [EMAIL PROTECTED] wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that each adds to the base specification. -Tim
+1 for this pace - the tangible
On 15/1/05 7:37 AM, Danny Ayers [EMAIL PROTECTED] wrote:
If I remember correctly from previous discussions, there is a little
snag with most browsers only passing the data, not the source URI.
Thing is, with the spec as it currently stands, we don't have a link
from the feed that can be
-1
I still have misgivings about the underlying model, mainly due to it's
binary nature. What happens if at some future point we want to rev the
definition of some element which has already been revved once before in it's
history? It already has the mU wart, and thus version 3 of that element
On 11/1/05 6:59 AM, Danny Ayers [EMAIL PROTECTED] wrote:
Ok, I don't think there is any benefit in the normal case (feed ::=
meta, (meta, content)*), but the recursive nesting method makes it
possible to convey information about relationships between feeds.
Which begs the questions:
How
I've realised another use case for atom entry documents.
I'm using del.icio.us to track certain memes. For example:
http://del.icio.us/tag/atom
http://del.icio.us/tag/rss
http://del.icio.us/tag/folksonomy
For each of those pages they offer an RSS feed. The feed's entries contain
the
On 6/1/05 12:26 PM, Tim Bray [EMAIL PROTECTED] wrote:
1. We *must* finalize the format. Our deadline is drawing near and we
need to focus on the publishing protocol.
Aside from focusing on the publishing protocol, which is well due, what else
happens after we finalise the format spec?
On 22/12/04 11:44 AM, Bob Wyman [EMAIL PROTECTED] wrote:
Eric Scheid wrote:
Looking at the list of elements one would find in a head leaves
me wondering what other elements you might want.
Title, Link, Author, tagline, and others... As well as any
extension stuff that might be there.
Feed
301 - 319 of 319 matches
Mail list logo
