Robert Sayre wrote:
Bill de hÓra wrote:
- I believe atomfeed and
...?
I was going to say something about schematron - don't mind it. The spec
will be clearer for leaving the schematron in.
cheers
Bill
One is an alias for the other. They're currently interchangeable from a
sending perspective.
-Scott-
> -Original Message-
> From: Mark Nottingham [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 06, 2005 11:43 PM
> To: Scott Hollenbeck
> Cc: atom-syntax@imc.org
> Subject: Re: AD Revi
Sam Ruby wrote:
If, instead, it opens the door for multiple changes without explicit
rationale; at the last minute; overturning carefully formed consensus;
then it was not.
Uh, so your changes are ok, but mine aren't? We continue the lovely
pattern of DOSing proposals.
I am willing to go with P
Sam Ruby wrote:
Tim Bray wrote:
On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote:
""?
No. --Tim
Some text.
I've incorporated Sam's suggested wording.
Robert Sayre
Robert Sayre wrote:
Sam Ruby wrote:
If, instead, it opens the door for multiple changes without explicit
rationale; at the last minute; overturning carefully formed consensus;
then it was not.
Uh, so your changes are ok, but mine aren't? We continue the lovely
pattern of DOSing proposals.
Unfair
Tim Bray wrote:
On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote:
Sam Ruby wrote:
An additional observation: neither of the examples in section 1.1
include the summary element. Suggestion: change the "content" in the
first (minimal) example to "summary".
""?
No. --Tim
Perhaps it would help if I wa
Sam Ruby wrote:
At this point, small surgical changes to address specific concerns may
(or may not) be acceptable. Wholesale changes with little rationale are
less likely to be so.
Well, who really cares anyway. I'll get the draft ready. Nobody propose
any 'wholesale changes' in the meantime, O
Robert Sayre wrote:
Sam Ruby wrote:
Content remains optional.
The pace did not drop the requirement for a link element in the absence
of content.
OK, I missed that. What else did I miss at this late date?
As it stands, this Pace declares co-constraints bad, selectively removes
a few co-constrain
Here is a nice small surgical change.
I am not sure if I have convinced Thomas Broyer with the diagrams I put
online,
but I am still very happy with the following replacement, after having
carefully
looked at the criticisms.
Proposal A
--
replace
[[
The value "alternate" signifies that t
On Apr 6, 2005, at 8:45 PM, Robert Sayre wrote:
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You are incorrect. There was an extended discussion, with Mark
Pilgrim steadfastly refusing to let the hideous old
multipart/alternate go until we had another proposal
Tim Bray wrote:
Actually, the argument was that if the content is either non-textual or
remote, a summary is beneficial to accessibility. I agree that many
people made this argument, sufficient in the co-chairs' minds to
establish rough consensus.
I understand the argument if the content is non
As many are aware, the Tim Bray[1] and others have recently been
railing on the subject of duplicate entries being delivered by aggregation
services and/or search engines like PubSub, Technorati, Feedster, etc. As
unexpected as this may sound, I am quite confident that when Atom V1.0 is
rel
Bob Wyman wrote:
Unfortunately, while RSS and Atom
both contain mechanisms to identify their "HTML" alternates, there isn't any
clear mechanism available to discover alternate feeds.
Without responding to the rest of the message, I'll note that this
statement is somewhat inaccurate wrt Atom. You c
This seems similar to what exists in Really Simply Discoverability in the
individual element [1].
-
# has 4 required attributes.
* "preferred" is a boolean and takes either "true" or "false". The point is
to allow weblog software to list all the APIs supported, but choose which one
to
Robert Sayre wrote:
> You can point to an alternate feed like this
>
> Of course, you can't have two alternates with the same media type...
Yes, you can point to an alternate. However, all you are doing at
that point is establishing equivalence between the two. The "alternate"
mechanism d
/ "Bob Wyman" <[EMAIL PROTECTED]> was heard to say:
| A major cause of duplicates in at least some of the existing
| services is the fact that bloggers insist on engaging in the apparently
| illogical and wasteful practice of publish multiple versions of their feeds
| and thus duplicates of t
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
Of course, you can't have two alternates with the same media type...
Yes, you can point to an alternate. However, all you are doing at
that point is establishing equivalence between the two. The "alternate"
mecha
Robert Sayre wrote:
>> Establishing equivalence only addresses a part of the problem.
> Fully agree. I just wanted to point out that a part of the problem is
> more solved than your post indicated.
My apologies if I made the situation sound more dire than it is.
However, even with th
* Bob Wyman <[EMAIL PROTECTED]> [2005-04-07 19:45]:
> I.e. if I didn't like something you published, I would simply
> publish something in my blog that had the same atom:id as
> something you had published. PubSub and other synthetic feed
> producers would then flush your post from the system and
Spaces.msn.com recently announced support for "slash:comments," an
element which shows how many comments an RSS item has associated with it.
As Dare Obasanjo explains[1]:
"Another cool RSS enhancement is that the number of comments on
each post is now provided using the sl
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
Of course, you can't have two alternates with the same media type...
Yes, you can point to an alternate. However, all you are doing at
that point is establishing equivalence between the two. The "alternate"
mecha
On Apr 7, 2005, at 10:34 AM, Bob Wyman wrote:
Tim suggests that aggregators should be able to rely simply on
atom:id to detect duplicates. However, as has often been pointed out,
applying this rule in an intermediary like PubSub would simply make
PubSub a
marvelously efficient tool for denial of
I don't think this is within the scope of Atom or any other spec. If
you want to differentiate your others, why not invest some time in a
decent duplicate detection algorithm like Google did? This is your
problem.
Graham
On 7 Apr 2005, at 7:29 pm, Bob Wyman wrote:
Robert Sayre wrote:
Establis
One way to look at this is to define what parts are local content
as opposed to caches of remote, and base the Etag or other hash on
that.
I still think we should address caching in Atom 1.0. This would
have been part of that. Scaling is an essential thing for syndication,
and caching is the best k
On 7 Apr 2005, at 7:48 pm, Bob Wyman wrote:
Of course, the side effect of this change is that any aggregator
that uses an MD5-like approach to detect changes will now think that an
entry has been updated every time a new comment is made. This may or
may not
be what is desired by consumers of feed
Graham wrote:
On 7 Apr 2005, at 7:48 pm, Bob Wyman wrote:
Of course, the side effect of this change is that any aggregator
that uses an MD5-like approach to detect changes will now think that an
entry has been updated every time a new comment is made. This may or
may not
be what is desired by
Tim Bray wrote:
1. A new feed-level element , any number allowed.
E.g.
http://www.tbray.org/ongoing/
http://www.tbray.org/
http://tbray.org/
http://www.textuality.comAlthough this doesn't solve the DOS potential, I'd rather go for a new
atom:source child element indicating the source f
Graham wrote:
> I don't seriously believe any aggregator that uses the content hash
> approach would survive very long in the market place without being
> buried under user complaints. Most (the one's I know of) either use
> identifiers or failing that some subset of the elements.
The "ide
Thomas Broyer wrote:
> When PlanetBar and PlanetFoo republish a feed from Baz, they should
> "move" the entry metadata into an atom:source element.
This is actually what we do at PubSub today. You may not be aware
that the atom:source element is modeled on the ps:source-feed element that
w
Thomas Broyer wrote:
Tim Bray wrote:
1. A new feed-level element , any number
allowed. E.g.
http://www.tbray.org/ongoing/
http://www.tbray.org/
http://tbray.org/
http://www.textuality.com
Although this doesn't solve the DOS potential, I'd rather go for a new
atom:source child element i
Tim Bray wrote:
>Would the following work:
>1. A new feed-level element , any number allowed.
>
> http://www.tbray.org/ongoing/
> http://www.tbray.org/
> http://tbray.org/
I don't like this. Hopefully, I can explain why. The reason is a bit
subtle...
Tim's proposal relies on
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, which
Atom supports, you have a mechanism that allow
* Bob Wyman <[EMAIL PROTECTED]> [2005-04-07 21:30]:
> Can/Should this subset be commonly known? It seems to me that
> it is important enough to the atom-ecosphere that it might even
> make sense to have it in the spec as an important
> interoperability note. i.e. "Entries will be considered
> dupl
Bill de hÓra wrote:
Thomas Broyer wrote:
Although this doesn't solve the DOS potential, I'd rather go for a new
atom:source child element indicating the source feed's Id or URI. When
PlanetBar and PlanetFoo republish a feed from Baz, they should "move"
the entry metadata into an atom:source elem
* A. Pagaltzis <[EMAIL PROTECTED]> [2005-04-07 22:55]:
> F.ex, entries maliciously published with someone elseâs 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 he
Robert Sayre wrote:
Sam Ruby wrote:
At this point, small surgical changes to address specific concerns may
(or may not) be acceptable. Wholesale changes with little rationale
are less likely to be so.
Well, who really cares anyway. I'll get the draft ready. Nobody propose
any 'wholesale changes
According to the RelaxNG:
>atomSource =
> element atom:source {
> atomCommonAttributes,
> (atomAuthor?
> & atomCategory*
> & atomContributor*
> & atomCopyright?
> & atomGenerator?
> & atomIcon?
> & atomId?
>
* 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
Thursday, April 7, 2005, 8:10:18 PM, you wrote:
> I still think we should address caching in Atom 1.0. This would
> have been part of that. Scaling is an essential thing for syndication,
> and caching is the best known way to scale.
Me too.
I'd like to see: atom:etag or atom:instanceId; or alt
Sam Ruby wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
Yeah, but we can't really legislate that, can we? We are making
editorial decisions for publishers via validity constraints.
You have made a num
On Apr 7, 2005, at 2:22 PM, Robert Sayre wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
Yeah, but we can't really legislate that, can we? We are making
editorial decisions for publishers via validity c
* Robert Sayre <[EMAIL PROTECTED]> [2005-04-07 17:22-0400]
>
> Sam Ruby wrote:
>
> >
> >Whether it is for accessibility, or for general usability, I want to
> >ensure that every entry has a textual, non-remote component to it.
+1
> Yeah, but we can't really legislate that, can we? We are mak
Dan Brickley wrote:
* Robert Sayre <[EMAIL PROTECTED]> [2005-04-07 17:22-0400]
Sam Ruby wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
+1
Yeah, but we can't really legislate that, can we? We are ma
David Powell wrote:
According to the RelaxNG:
atomSource =
element atom:source {
atomCommonAttributes,
(atomAuthor?
& atomCategory*
& atomContributor*
& atomCopyright?
& atomGenerator?
& atomIcon?
& atomId?
& ato
I'm currently experimenting with writing an XSLT stylesheet that
transforms RSS 2.0 into the same RDF/XML model that my atom2rdf
stylesheet[1] creates.
Do we have an equivalent to RSS's [2] element? This is a
pretty widely used feature of RSS — does it deserve a link/@rel value
in Atom?
[1] ht
Thomas Broyer wrote:
Bill de hÓra wrote:
Thomas Broyer wrote:
Although this doesn't solve the DOS potential, I'd rather go for a
new atom:source child element indicating the source feed's Id or URI.
When PlanetBar and PlanetFoo republish a feed from Baz, they should
"move" the entry metadata int
> - in 6.4; extension schema allow the use of the atom namespace as child
> elements of the extension. I do not recall this being discussed, but
> personally am +1 to it.
Yeah, I'm ok with it too. I'm not sure why anyone would want to do it,
but the spirit of Structured Extension elements was th
Bill de hÓra wrote:
Thomas Broyer wrote:
Bill de hÓra wrote:
Thomas Broyer wrote:
Although this doesn't solve the DOS potential, I'd rather go for a
new atom:source child element indicating the source feed's Id or
URI. When PlanetBar and PlanetFoo republish a feed from Baz, they
should "move" th
Thomas Broyer wrote in response to Bill de hÓra:
> If an entry already has an atom:source child, you just republish
> it as-is. [And, if it doesn't have an atom:source, you insert one.]
This is what was agreed, I believe, when the issue was discussed on
the list. To do anything more would
Personally, I think the atom:source should have a required link which points
to the feed that is claimed to be the source...
bob wyman
The inheritance of @xml:lang and @xml:base creates a lot of
complexities for an implementation. When they are used in combination
with atom:source, things get particularly bad.
Should we add some notes to the spec to remind people how to correctly
handle base and lang when atom:source-ifying ent
+1 to adding these kinds of clarifications and examples to the spec!
Regards, Martin.
At 08:02 05/04/08, David Powell wrote:
>
>
>The inheritance of @xml:lang and @xml:base creates a lot of
>complexities for an implementation. When they are used in combination
>with atom:source, things get partic
Bob Wyman wrote:
Thomas Broyer wrote in response to Bill de hÓra:
If an entry already has an atom:source child, you just republish
it as-is. [And, if it doesn't have an atom:source, you insert one.]
This is what was agreed, I believe, when the issue was discussed on
the list. To do anything more w
Friday, April 8, 2005, 12:13:40 AM, Martin Duerst wrote:
> +1 to adding these kinds of clarifications and examples to the spec!
The simplest thing would probably be to RECOMMEND that processors
resolve the base and lang values for the atom:entry and atom:feed
elements of source feed, and explic
On 8/4/05 6:17 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> A side benefit of having "primary feeds" would be that people would
> be more likely to do things like include full "category" data in the entries
> they publish rather than publishing entries into specialized feeds as the
> way to indic
On 8/4/05 6:17 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
> The proposal I made relies on a feed making statements only about
> itself. In my proposal, a feed can only say: "I contain copies of these
> other feeds. I am a secondary feed."
How does this prevent DOS attacks? If I could insert entr
On 8/4/05 6:49 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I don¹t believe we can forsee
> all of these, so let¹s not try to. The Atom format should specify
> hooks (such as the atom:source subelement Thomas suggested,
> possibly?) which would allow trust models or other coping
> mechanisms t
Eric Scheid wrote:
>>On 8/4/05 6:17 AM, "Bob Wyman" <[EMAIL PROTECTED]> wrote:
>> The proposal I made relies on a feed making statements only about
>> itself. In my proposal, a feed can only say: "I contain copies of
>> these other feeds. I am a secondary feed."
> How does this prevent DOS attacks
Tim Bray wrote:
You are implying that would be somehow inappropriate or
unsportsmanlike. It isn't. If there is consensus, such a challenge
would be squashed rather quickly, don't you think?
Just for the record, I strongly agree that Atom entries should be
required to include (to use Sam's words
62 matches
Mail list logo
