Hi,
I'm building a tool (for Plone) at the moment that will publish any
content as an Atom Entry by appending '/entry.xml' onto the URL. I had a
question about declaring self and alternate links. Here are two options:
1:
@rel=self,@type=application/xml+atom links to the Entry
Jan Algermissen wrote:
Hi,
is it really true that the Atom namespace is http://www.w3.org/2005/Atom ?
Meaning that it is somewhat difficult to identify Atom elements with URIs:
http://www.w3.org/2005/Atomauthor
http://www.w3.org/2005/Atomconributor
Was that simply a mistake or a
Bob Wyman wrote:
The impact here is not just limited to APP implementations. If a new
media type is defined, it will undoubtedly appear in other contexts as
well. Given the current definition of the atom syntax, it is perfectly
reasonable for an aggregator to treat a single entry as the
Mark Baker wrote:
Isn't that just a case of people not implementing the whole spec
though?
Not really. The RFC defines the structure, not so much the interaction
model around feeds (which is driven by UIs more than anything else, so I
can buy into it being somewhat arbitrary)
Or, are
Antone Roundy wrote:
On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:
Following a link is not the same thing as subscribing to something.
The act of subscribing is a local activity performed by the user
agent. What you do when you follow the link to a feed is a GET. Your
agent then
Hi,
I'm sending entries over XMPP packaged up as feeds. A question that has
come up - should the feed's atom:id change each time a feed is sent, or
should it remain the same for all feeds issued from a client?
cheers
Bill
Mark Baker wrote:
On 12/4/06, James M Snell [EMAIL PROTECTED] wrote:
All I can go on is evidence of how folks are actually using 'em... and
they ain't using 'em as aliases. :-)
Ok, I'll take empirical evidence too 8-) Point the way ...
Mark,
since you introduced it, what's an alias,
James M Snell wrote:
When I process this entry,
http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0
I had problems subscribing to that entry in bloglines. Will somebody
file a bug?
cheers
Bill
James M Snell wrote:
Mark Baker wrote:
[snip]
Yes, but more than that. An entry document is, AFAICT, little more
than shorthand for a feed with one entry, minus the feed-specific
metadata. It's processing is a subset of feed processing. If the
processing or content model of entry is
A. Pagaltzis wrote:
* Mark Baker [EMAIL PROTECTED] [2006-11-29 20:10]:
An entry document is, AFAICT, little more than shorthand for
a feed with one entry, minus the feed-specific metadata. It's
processing is a subset of feed processing. If the processing or
content model of entry is extended,
Well it's all octets so in one sense the processing is the same.
I have to agree with James.
The right questions in my mind is this - how is processing an entry
different from processing a feed with that and 42 entries?
The idea that an entry is a degenerate feed is interesting, but
Mark Baker wrote:
[..] it it's
better than the alternative of many more specific Atom-related media
types, which atomentry+xml might set a precedent for.
One question and one observation. The question: how will this set a
precedent? The observation: if we really want to avoid this problem
Mark Nottingham wrote:
Sorry, this got lost in my inbox...
I think they do, although the draft is silent on it. This is one of
those areas where it would have been really nice if the WG had agreed to
take on FH as part of the core, rather than extension; there are lots of
little
Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up any
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
in XHTML.
Thoughts?
Foreign markup is ambiguous.
[[[
Markup from other vocabularies (foreign markup) can be used in an
Atom
A. Pagaltzis wrote:
I think given the above background you'll agree that the intent
of the document is pretty coherent.
I couldn't tell whether new Atom extensions are foreign markup, or
something else to be dealt with under wrt being a forward-compatible
friendly consumer. It's kind of
Alastair Rankine wrote:
Hello Atom folks,
Here is a proposal for an Atom-derived format for exporting of content.
The problem I'm trying to solve is that of migration from one authoring
system (eg blogging engine) to another. Atom is highly suited to this task.
The full problem statement,
16 matches
Mail list logo
