* Sam Ruby [EMAIL PROTECTED] [2005-04-03 04:30]:
Every version of RSS has required this link. I've *never*
heard anybody complain about this in the context of any version
of RSS. It puzzles the bejeebers out of me why this issue is
only brought up in the context of Atom.
My guess is that
* A. Pagaltzis [EMAIL PROTECTED] [2005-04-07 22:55]:
F.ex, entries maliciously published with someone elses entry
ID will not actually constitute a DOS attack for consumers
whose aggregator maintains a history of previously seen
versions of an entry.
Sorry, wrong thread. I have been
* Bob Wyman [EMAIL PROTECTED] [2005-04-07 22:40]:
A. Pagaltzis wrote:
But it breaks down for the aggregate feeds published by third
parties. If look at more convoluted examples, it fast turns
into web of trust territory...
You are correct -- with one caveat. If entries are signed,
Yes
* Sam Ruby [EMAIL PROTECTED] [2005-04-09 22:30]:
What compelling use case would enabling the omission of
non-remote, textual content - i.e., not merely providing a zero
length content, but the outright omission of same - enable?
I have no opinion either way (not that it would have much
* James Aylett [EMAIL PROTECTED] [2005-04-10 11:55]:
On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote:
* the atom:entry contains an atom:content that has a src
attribute (and is thus empty).
FWIW, for clarity I would favour:
'... has a src attribute (and is thus itself
* Asbjrn Ulsberg [EMAIL PROTECTED] [2005-04-13 02:35]:
Or, we should restrict the allowed XHTML versions in the
specification to just include 1.x. That leads to different
problems, though, since people would then think they could use
XHTML 1.0 Frameset or XHTML 1.1, which are totally
* David Powell [EMAIL PROTECTED] [2005-04-13 21:50]:
I agree that the Atom RFC shouldn't be a moving target. How
about if we:
Make an IANA registry of Atom Text Types, requiring some
level of RFC to create new ones.
Put text, html, and xhtml in the registry, and specify that
* A. Pagaltzis [EMAIL PROTECTED] [2005-04-15 20:20]:
* Antone Roundy [EMAIL PROTECTED] [2005-04-15 00:10]:
feed xmlns=our namespace URI
...
atom:content type=XHTML xmlns:atom=our namespace URI
xmlns=XHTML's namespace URI
divThis is XHTML content,br /
and the default namespace
* Robert Sayre [EMAIL PROTECTED] [2005-04-16 21:45]:
Atom Processors MAY display it using normal text rendering
techniques such as proportional fonts, white-space collapsing,
and justification.
MAY or MAY NOT. There's no right answer in there right now.
Would @xml:space be applicable if I
* Tim Bray [EMAIL PROTECTED] [2005-04-25 20:35]:
I decided it would help if there was an actual Pace:
http://www.intertwingly.net/wiki/pie/PaceOptionalSummary
So far I havent seen a cogent explanation of the significant
semantics offered by an empty atom:summary inside an otherwise
valid
* Sam Ruby [EMAIL PROTECTED] [2005-04-27 12:45]:
So.. can we agree on SHOULD?
+1. My previous tentative +1 for MAY is hereby withdrawn.
Regards,
--
Aristotle
* Robert Sayre [EMAIL PROTECTED] [2005-04-30 22:15]:
Remove the bullet point that reads
{{{ atom:feed elements MUST NOT contain atom:entry elements
with identical atom:id values. }}}
Add a paragraph after the list that reads
{{{
Atom Processors use the atom:id element found in Atom
* Eric Scheid [EMAIL PROTECTED] [2005-05-01 18:45]:
perhaps we need to explain the concept of 'entries' (as
resources), as distinct from entrys (as representations), and
explain that 'entries' must have unique IDs, and that the
atom:id element of any atom:entry ties it back to the
'entry'
* Thomas Broyer [EMAIL PROTECTED] [2005-05-03 19:35]:
This means type=text content is a single paragraph of text.
If you need paragraphs, lists or any other structural
formatting, you have to use type=html or type=xhtml with
the appropriate content.
Or type=text/plain, Id assume?
Regards,
* Tim Bray [EMAIL PROTECTED] [2005-05-10 04:40]:
We definitely need some quick, snappy label to refer to that
version to distinguish it from Atom 0.3
there'll be no actual spec-based reason to call our product
Atom 1.0. But, we could just go ahead and do it anyhow.
+1 for Atom 1.0 since a
* Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]:
Perhaps that can be offset by producing text that urges the
publisher to consider emitting summaries.
Maybe its something for the implemetors guide as opposed to the
spec, then?
Regards,
--
Aristotle
* Bill de hra [EMAIL PROTECTED] [2005-05-11 17:05]:
ARSS, short for Atom RSS. The marketing possibilities are
endless.
How about Atom Syndication Standard?
I guess the Firefox crowd can then resurrect the non-Wifi looking
autodiscovery icon.
Regards,
--
Aristotle
On Saturday, May 14, 2005, at 10:36 AM, Kevin Marks wrote:
After seeing 'in the wild' what I consider badly-formed Atom feeds,
where both the atom:summary and atom:content contain identical
abbreviated entry text, I realised that the spec does not make this
clear.
* Thomas Broyer [EMAIL PROTECTED] [2005-05-15 17:10]:
A. Pagaltzis wrote:
The atom:content element either contains or links to the
full content of the entry. An atom:entry containing an
atom:content element MUST be a complete representation of
the entry. If the atom:entry
* Graham [EMAIL PROTECTED] [2005-05-16 01:10]:
Let's say I put the first sentence of each post in
atom:summary. What happens when I post a one sentence entry?
Then you must not put it in the summary. And this is my opinion
independent of the pace.
An even half-way intelligent user agent would
* Graham [EMAIL PROTECTED] [2005-05-16 01:15]:
An atom:entry MUST NOT have both an atom:content and an
atom:summary element with identical content.
-1
It might solve this exact problem, but in the general case it
makes no sense.
Besides my point in the other mail, I wanted to
* James Tauber [EMAIL PROTECTED] [2005-05-16 05:45]:
I believe it is reasonable to:
1. include a summary element in my full-content feed in
addition to the content element; and
Absolutely it is. F.ex, user agents could provide the summary in
addition to the title of an entry in a feed
* Graham [EMAIL PROTECTED] [2005-05-18 23:15]:
On 18 May 2005, at 9:36 pm, Robert Sayre wrote:
Regardless of how an associated application will handle
entries with no atom:summary element, all Atom Processors MUST
NOT fail to process Atom entries simply because they contain
no atom:summary
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 17:50]:
contributor
category term=Author/
nameBarnable Foo/name
.../
/contributor
+1
Very elegant.
As for the inheritance problem this does bring up: the current
spec implicitly defines that no
* Graham [EMAIL PROTECTED] [2005-05-20 20:30]:
Well unless we make category/term machine readable, we might as
well just have a plain text blob.
But we already did that. Theres an option @scheme attribute for
atom:category. Thats part of the elegance of this approach.
Regards,
--
Aristotle
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 20:10]:
On 21/5/05 3:41 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
However, it does pose a problem of default semantics. Do we
define particular categories in the spec? If we dont, do we
define a default category to be assumed in absence
* Eric Scheid [EMAIL PROTECTED] [2005-05-20 19:55]:
6.4Extension Elements
Atom allows foreign markup anywhere in an Atom document.
does this mean this is allowed:
title type=texthello world!foo:evil:-)/foo:evil/title
You request adding except where they are explicitly forbidden
* Eric Scheid [EMAIL PROTECTED] [2005-05-21 17:30]:
what if author in that example was renamed to byline (and
specced to be something other than a Person Construct),
+1, calling it author when that sort of usage is expected and
encouraged is a lie.
and some mechanism introduced to indicate
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]:
At this stage, changing the spec to suit religious preferences
would be extremely arrogant.
Please stop talking to people about process bullshit at one
occasion and turning around to chide others for at this stage
at the next.
Regards,
--
* Antone Roundy [EMAIL PROTECTED] [2005-05-22 05:25]:
Multiple authors:
* Allow multiple atom:author elements per feed/entry
* Keep atom:contributor
* Leave byline or ordering of authors to an extension for
those who need it
+1
Multiple instances of an entry in a feed document
* Allow it
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 21:25]:
On 5/21/05, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-05-21 19:05]:
At this stage, changing the spec to suit religious
preferences would be extremely arrogant.
Please stop talking to people about
* Tim Bray [EMAIL PROTECTED] [2005-05-22 04:50]:
I do not agree in the slightest that atom:modified is any more
useful than atom:updated for these purposes. The only
distinction between modified and updated is that there might be
changes, not considered significant by the publisher, which
* Bob Wyman [EMAIL PROTECTED] [2005-05-22 08:05]:
I'll be making a presentation on Tuesday which will include a
slide on how Atom improves on RSS. If you have any thoughts on
this subject, I would appreciate hearing them.
I think the main attractions are pretty clear:
Thoroughly specified
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of
XHTML? (I really dislike this combined construct by the way.)
I used to find it extremely horrible. Now Im not sure.
There is some symmetry
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 3.1.1.3 XHTML
I would like to see valid XHTML more clearly defined. There
are a lot of different XHTML versions I know of and some might
not include a DIV element at all... You have XHTML 1 (in three
versions), XHTML 1.1, XHTML
* Tim Bray [EMAIL PROTECTED] [2005-05-23 07:00]:
Unfortunately, among those who want to change the current
setup, we do not observe consensus on the subject of what to
change them to. Near as we can tell, people want to make
atom:author plural, some want to nuke atom:contributor and
others
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 09:05]:
Robert Sayre wrote:
For white-space significance text I need to use 'html' or
'xhtml' instead using PRE or xhtml:pre?
I don't understand what you're saying here, but I'm pretty
sure every possible whitespace issue has been debated
* Thomas Broyer [EMAIL PROTECTED] [2005-05-23 10:50]:
A. Pagaltzis wrote:
There is some symmetry here: with @type=xml, you have to
Which @type=xml? Did you mean @type=text/xml?
Sorry, I meant any XML media type.
enclose a full XML document, which will always have a root
element
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 10:35]:
A. Pagaltzis wrote:
Last I asked, I understood that whitespace would be preserved
if you supply 'text/plain' content; @type='text' is more like
inline text in an XML document (or in HTML). Maybe the spec
could be more explicit about
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]:
What is the interop problem you are trying to avoid? You don't
just throw in a SHOULD NOT and say otherwise it would be
hard.
How else would you present a list of distinct authors for a set
of entries? What is the point of allowing multiple
* Graham [EMAIL PROTECTED] [2005-05-23 12:50]:
http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor
+1
Regards,
--
Aristotle
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]:
-1 to atom:byline, should anyone propose it.
We already have pretty good consensus that bylines, if needed by
anyone, will be implemented in an extension, not in Atom. No need
to punch it down here again separately.
Regards,
--
Aristotle
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 14:45]:
On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]:
-1 to atom:byline, should anyone propose it.
We already have pretty good consensus that bylines, if needed
by anyone
* James Aylett [EMAIL PROTECTED] [2005-05-23 15:15]:
I think we're trying to do too much here. Why on earth are we
disallowing a list of authors that includes the same person
twice? Why does it actually cause problems? I can write the
following English sentence:
The book was written by
* Dan Brickley [EMAIL PROTECTED] [2005-05-23 16:40]:
It would be good if Atom were clear on whether repetition of
the exact same name implies the two authors are distinct (eg.
things written by father/son pairings, where they have same
name).
Doesnt seem to me like there should be any
* Eric Scheid [EMAIL PROTECTED] [2005-05-24 01:40]:
Consider too a feed which has both authors and contributors at
the feed level, an entry with neither authors or contributors
(simple case of inheritance), and another entry with a single
author and no contributors (does the entry inherit the
* James Cerra [EMAIL PROTECTED] [2005-05-24 06:35]:
XML 1.1
Not supported.
I'm confused. There is nothing inherent in the spec that
prevents XML 1.1 or any future versions from being supported.
And why introduce incompatibilities in atom:content that also
bork with arbitrary XML
* Thomas Broyer [EMAIL PROTECTED] [2005-05-24 09:05]:
a)
feed:
author: A
contributor: B
entry:
no author not contributor
b)
feed:
author: A
contributor: B
entry:
author: C
c)
feed:
author: A
contributor: B
entry:
contributor: C
d)
feed:
* Karl Dubost [EMAIL PROTECTED] [2005-05-24 20:05]:
It means that all XSLTs, Web hosting services, etc can NOT
claim conformance to Atom. :)
Yes they can.
no for the reason I gave and no because there's no way to claim
conformance to the spec. They are plenty marketing department
* Thomas Broyer [EMAIL PROTECTED] [2005-05-24 15:15]:
A. Pagaltzis wrote:
* Thomas Broyer [2005-05-24 09:05]:
c)
feed:
author: A
contributor: B
entry:
contributor: C
[...]
c) The entry inherits the author but overrides the
contributor. I'm also open to considering
* James Cerra [EMAIL PROTECTED] [2005-05-26 05:35]:
Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still
inappropriately use comments for that purpose. Then there are
example XML documents (i.e. for tutorials) that sometimes
require comments be preserved.
Entities can be
* Henri Sivonen [EMAIL PROTECTED] [2005-05-26 10:20]:
On May 26, 2005, at 06:23, James Cerra wrote:
Yes, but MSIE^H^H^H^Hsome xml processors (cough cough) still
inappropriately use comments for that purpose.
I am not familiar with that. What purpose exactly? Why should
Atom support it?
* James Cerra [EMAIL PROTECTED] [2005-05-28 04:00]:
Nothing prevents anyone from writing a generator or pre- or
postprocessor for Atom documents to cater to the needs of
their particular brand of broken software. Wrangling that
particular piece of broken software however is their job; not
* Eric Scheid [EMAIL PROTECTED] [2005-05-28 11:00]:
An Atom Entry can have XML content, right...
Consider this example:
Entirely legal, but who wants to bet the feed validator throws
a fit ;-)
Most aggregators will probably ignore the content, and likely not
even do anything useful with
* James Cerra [EMAIL PROTECTED] [2005-05-30 03:20]:
Depending on an entity reference and not being able to
accept the straight replacement text is just wrong.
I agree. I'm just bringing up possible incompatibilities
for debate!
I don't think that's an incompatibility that
,
--
Aristotle Pagaltzis // http://plasmasturm.org/
?) for that sort of thing
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
to do with
multipart/*, then great. But if it doesnt, then the Atom
processor certainly wont care one way or the other.
Funnily enough, thats exactly the same treatment that any other
known or unknown MIME type receives.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
* Graham [EMAIL PROTECTED] [2005-06-18 21:50]:
The better way to do this is to use atom:link rel=alternate
to reference the messages.
Is there any verbiage that would preclude a data: URI with a
multipart payload in atom:link?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
it with a @link attribute on the Name
Construct’s root element.
But, as mentioned, the spec, modulo bugs, is a done deal at this
point.
And if the atom:uri element’s naming really turns out to be the
biggest wart in the spec, then I’ll gladly suffer it. :-)
Regards,
--
Aristotle Pagaltzis // http
containing all
entries, and use RFC3229+feed to return partial versions of it;
as far as I can tell, this is a use case which your draft does
*NOT* allow. Is that so?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Documents MUST use Canonical XML
by default; they MAY use other canonicalizations at user request.
I agree, but I think the second wording is confusing. It doesn’t
actually say anything different from the first wording, even
though it seems to imply more.
Regards,
--
Aristotle Pagaltzis // http
be
Atom Processors that sign Atom Documents MUST support the use
of Canonical XML.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
which inform
the client how to request the entirety of the feed – maybe
Resource-Initial-ETag or something like that.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
* Eric Scheid [EMAIL PROTECTED] [2005-07-01 11:25]:
On 1/7/05 7:01 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Atom Processors that sign Atom Documents MUST support the
use of Canonical XML.
what about Atom Processors that are not signing stuff, but is
instead reading/validating
in any way, it
just explicates ramifications of the spec as it already stands,)
it would be a very worthwhile addition.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
* Paul Hoffman [EMAIL PROTECTED] [2005-07-06 01:20]:
Does anyone object to the following exact wording being added
right after the new paragraph on canonicalizing:
Not me. +1 to the addition.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
think defining an extension element as
outlined above and providing a unified feed of comments for all
entries makes the most sense.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
before aggregators and producers all support the new spec
in unison.
So in light of these and Robert’s arguments, there’s no apparent
reason to attempt to interoperate.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
? An alternative might be
to define a format for this need that used Atom elements but
had minimalized cardinality requirements.
That’s a really drastic measure for such negligible benefit.
One Format To Rule Them All, as far as I’m concerned.
Regards,
--
Aristotle Pagaltzis // http
liking this a lot.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
feed which the particular
aggregator does not subscribe.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
of the change might be considered too major.
Unless maybe it’s argued that this was what the spec said all
along, and this change therefore is just clarification? I don’t
know. Colour me lost.)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
remains one and the same: the aggregator must
somehow be able to tell that some of the linked feeds are highly
relevant, whereas others are merely of tangential interest.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
the waters semantically such that loosely related
extraneous feeds cannot be distinguished from highly relevant
ones – without offering any actaul simplicity at all in return.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-13 08:11]:
Obviously, my own vote is that it’s fine as is: I see no reason
that dictates that atom:link must point to a concrete Web
resource, rather than just an abstract one – neither
conceptually/semantically nor in terms of consequences
) would be
the logical choice for this particular use case, as they offer
defined semantics for attaching metadata directly to an entry.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
for Atom 0.3. If people
do give you that in return for a request for Atom 1.0, well, no
standard is going to be much help – the failure is at their end
and you simply can’t do anything about that.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
as they may
be –, but advises that the generation of new IDs should be
adjusted.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
? :-)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
solely
around RSS since there wouldn’t have been any Atom format to
think about. We should be glad that the spec was pushed through
at the final stages; a tip of the hat to the WG chairs and
members who insisted on making haste with a Good Enough text.
Regards,
--
Aristotle Pagaltzis // http
popular podcasts are probably RSS 2.0, but I would
be surprised if a number of podcasts aren’t provided in both
formats. I don’t know much about that, though, as I haven’t had
much interest in the phenomenon itself.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
aren’t likely to officially bless any such
effort, instead considering it the team’s responsibility to
figure things out, much like they seem to be doing with Safari
and its standards compliance. The cultures at the two companies
obviously differ.
Regards,
--
Aristotle Pagaltzis // http
that do that. The
browsers which know render feeds in a meaningful fashion by
themselves (Safari, Firefox+extension) do allow that.
Unsurprising, really, as feeds have yet to emerge into a lot of
areas outside weblogs or similarly structured content outlets.
Regards,
--
Aristotle Pagaltzis
, how can RFC3229+feed provide subsets where one end isn't
tied to the most recent entry?
It can’t. Is there a need for that beyond a minor overhead of
redundancy?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Ugh, I was as clear as mud.
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-17 06:20]:
It would make more sense to me to say that a particular type of
@rel value always expects a dereferencable URI or never expects
on. “in-reply-to” would be in the latter category.
I can see the value in having
* Sjoerd Visscher [EMAIL PROTECTED] [2005-07-19 01:25]:
A. Pagaltzis wrote:
He is correct, Tim. The base URI means “the URL where this
document was found,” not “the prefix for any enclosed relative
links.” I don’t see how RFC3986 can be read any other way.
I am correct ;), but your
by the fact that some issues may
never even have had a clear rationale. See f.ex. our current
debate about whether atom:link/@href was meant to always be
dereferencable or may be any URI at all, abstract or not.)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
,
--
Aristotle Pagaltzis // http://plasmasturm.org/
of sucks…
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
to the RFC, which
only considers a small subset of the possible use cases. So we
have a mismatched layering of specs, for a certain class of use
cases… ugh.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
is impossible.
How should any scheme you’d propose solve this? And is any such
scheme deployable on the web today?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
the public feed and all the
webpages. But I never need to write any entities, since that file
is UTF-8 and I edit it with gvim. (Insert “UTF-8 rocks” fanboy
praise.)
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
? And what does it mean
then?
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
to two
different entries.
Ah, the feed-level link simply inherits. Good idea, I like that.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
, a desktop aggregator would usually
show the HTML page returned with the error or a default – but of
course it should under no circumstances appear as if this was
part of the feed content.
This is really just ordinary interpretation of HTTP.
Regards,
--
Aristotle Pagaltzis // http
commonly returned with an error response would
be adequate for probably the majority of cases.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
,
--
Aristotle Pagaltzis // http://plasmasturm.org/
using their atom:ids, signifying
which entries belong to which others – like what we’re talking
about for comments in feeds.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
them.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
1 - 100 of 325 matches
Mail list logo
