Pascal Philippe wrote:
For example, in a web blog entry, I can have more than one components.
A web blog entry can be, as example, a picture (encoded in base64)
with a text. How can I represent this using the Atom syntax?
If you want the image to appear inline, you can include it as an HTML
On 12/10/05 7:54 PM, Pascal Philippe [EMAIL PROTECTED] wrote:
I would like to try to understand why we can't have more than one
atom:content element within an atom:entry element. Could you give me
the reason of this choice?
IIRC, it was thought it would be too burdensome for developers to
* James Holderness [EMAIL PROTECTED] [2005-10-13 09:40]:
If you want the image to appear inline, you can include it as
an HTML (or XHTML) img tag within the atom:content element.
Alternatively, if it would be better represented as an
attachment you can include it as an enclosure (an atom:link
A. Pagaltzis wrote:
And deviously, you can inline the image data inside the feed too,
by using a data: URI with one of these methods.
However, shipping blobs around inside a feed is not a bright idea
with the currently common feed use cases.
There's also the problem that Internet Explorer
James Holderness wrote:
A. Pagaltzis wrote:
And deviously, you can inline the image data inside the feed too,
by using a data: URI with one of these methods.
However, shipping blobs around inside a feed is not a bright idea
with the currently common feed use cases.
There's also the
* John Panzer [EMAIL PROTECTED] [2005-10-13 18:45]:
If I recall, I believe this is because some people wanted to be
able to package multiple pieces of content together in a single
entry, and other people did not want to have to imply a
requirement for MIME multipart parsing as pat of the Atom
I was wondering if someone might be able to summarize the issues
associated with a link rel=next and link rel=previous? What were
the primary objections?
I ask because it seems like a very logical core component for the spec,
especially as a link relation.
-Original Message-
From:
Does anyone know of an extension or mechanism that can
indicate whether a given feed is a complete representation of the content it
encompasses, or is just a summary?
Here is the use case:
Both LiveJournal and TypePad
give users the option of not
publishing the complete
A. Pagaltzis wrote:
* John Panzer [EMAIL PROTECTED] [2005-10-13 18:45]:
If I recall, I believe this is because some people wanted to be
able to package multiple pieces of content together in a single
entry, and other people did not want to have to imply a
requirement for MIME
* John Panzer [EMAIL PROTECTED] [2005-10-13 19:40]:
Well, you can pass them around by reference with [EMAIL PROTECTED]
I think.
By the letter of the spec, but not by the spirit.
But that’s beside the point, since if you’re going to point to an
external resource, you can and should use an
* Byrne Reese [EMAIL PROTECTED] [2005-10-13 19:40]:
In stead, we publish a summary of the post in the summary
element. That's logical enough. We see there being value
however in being able to communicate to the reader that the
contents represented by an entry element is not a complete
Six Apart is looking to develop an experimental implementation
of the Feed Thread extension for Atom. However, I have a few questions:
I see this extension as a logical place to list all feedback (both comments and trackbacks). However, I dont see a way for the extension to
Byrne Reese wrote:
Six Apart is looking to develop an experimental implementation of the
Feed Thread extension for Atom. However, I have a few questions:
I see this extension as a logical place to list all feedback (both comments and
trackbacks). However, I don’t see a way for the
On Oct 13, 2005, at 12:06 PM, A. Pagaltzis wrote:
* John Panzer [EMAIL PROTECTED] [2005-10-13 19:40]:
Well, you can pass them around by reference with [EMAIL PROTECTED]
I think.
By the letter of the spec, but not by the spirit.
I just ran through the discussion of this very question on the
* Byrne Reese [EMAIL PROTECTED] [2005-10-13 20:55]:
No I suppose not. But there are edge cases where people may not
include content in a post. They may simply use the title... in
maintaining a list of links for example. But I suppose there is
a difference between:
entry
titlefoo/title
On 10/10/05, James M Snell [EMAIL PROTECTED] wrote:
I've been considering asking the Opensearch folks if they would be
willing to separate their next/previous/first/last link relations out to
a separate spec that could be made a working group draft. The paging
functionality they offer
Thomas Broyer wrote:
Byrne Reese wrote:
Six Apart is looking to develop an experimental implementation of the
Feed Thread extension for Atom. However, I have a few questions:
I see this extension as a logical place to list all feedback (both
comments and trackbacks). However, I don’t
+1
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
Sent: Sunday, October 09, 2005 9:06 PM
To: James Holderness
Cc: Syntax Atom
Subject: Re: Feed History -04
I've been considering asking the Opensearch folks if they would be
willing to
Using Mark Nottingham's Feed History extension, you could do
fh:incrementalfalse/fh:incremental
Byrne Reese wrote:
Does anyone know of an extension or mechanism that can indicate
whether a given feed is a complete representation of the content it
encompasses, or is just a summary?
Here
Hi James,
* James M Snell [EMAIL PROTECTED] [2005-09-08 06:45]:
If anyone has any further comments on the draft, please let me
know.
I am alarmed that this draft does *not even once* explicitly
mention the fact that idrefs are expected to be derived from Atom
Entry IDs. No particular
On 13 Oct 2005, at 8:02 pm, A. Pagaltzis wrote:
If you want to ship a complete representation, you ship an
atom:entry, and if the resource is empty, then that atom:content
is empty.
If the atom:entry has no atom:content, then that always means
that it is a partial representation only.
On 10/13/05, Graham [EMAIL PROTECTED] wrote:
Point to any text in the spec that backs this up.
The spec says only The 'atom:content' element either contains or
links to the content of the entry.
Any assertion that there is no other content to be had is not
testable, and therefore rightly
John Panzer wrote:
If I recall, I believe this is because some people wanted to be
able to package multiple pieces of content together in a single
entry, and other people did not want to have to imply a
requirement for MIME multipart parsing as pat of the Atom
format specification.
Ugh.
If only to make the nature of a feed, or state of a feed more
deterministic and less ambiguous...?
Nottingham's Feed History achieves this objective for me. I *knew* I had
read something about this somewhere. :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
My understanding was that if fh:incremental was false the feed document
should be considered a complete replacement for any previous document you
may have received. This would be for things like top 10 lists.
I believe the question being asked here is actually about the entries
themselves
Ah, missed that, you're right. There is no way of indicating whether or
not a feed is a full-content feed vs. a summary feed beyond the presence
(or lack thereof) of the atom:content element.
James Holderness wrote:
My understanding was that if fh:incremental was false the feed
document
Graham wrote:
On 13 Oct 2005, at 8:02 pm, A. Pagaltzis wrote:
If you want to ship a complete representation, you ship an
atom:entry, and if the resource is empty, then that atom:content
is empty.
If the atom:entry has no atom:content, then that always means
that it is a partial representation
I've been considering moving feed history over to atom:link, but
wanted to check with people who are currently using / referring to
it, as well as with the RSS communities. Please give me a little time.
On 09/10/2005, at 9:06 PM, James M Snell wrote:
I've been considering asking the
Excellent. If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections into a
single set of paging link relations (next/previous/first/last).
Mark Nottingham wrote:
I've been considering moving feed history over to atom:link, but
On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote:
Excellent. If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections into a
single set of paging link relations (next/previous/first/last).
'first' or 'start'?
Do we
On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote:
On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote:
Excellent. If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections
into a
single set of paging link relations
* Antone Roundy [EMAIL PROTECTED] [2005-10-14 05:10]:
On Oct 13, 2005, at 7:58 PM, Eric Scheid wrote:
Do we need to define what 'first' means though? I recall a
dissenting opinion on the wiki that the 'first' entry could be
at either end of the list, which could surprise some.
Yeah,
On 10/13/05, Eric Scheid [EMAIL PROTECTED] wrote:
On 14/10/05 9:18 AM, James M Snell [EMAIL PROTECTED] wrote:
Excellent. If this works out, there is an opportunity to merge the
paging behavior of Feed History, OpenSearch and APP collections into a
single set of paging link relations
On 14/10/05 2:01 PM, Joe Gregorio [EMAIL PROTECTED] wrote:
Eric,
It's like deja-vu all over again.
http://bitworking.org/news/Atom_Auto_Sub_How_To
:)
I'd forgotten about that, I was only remembering the wiki.
I still think it odd that one could traverse both prev and next from the
34 matches
Mail list logo
