I've been working to add Atom support to Firefox 2. Some other Firefox
devs are toying with exposing internal data like history and bookmarks
as Atom feeds.
What software are you writing?
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
h the
>> same name.
>
> Well, you have all of these child elements that can change the effect
> of the element, so why would you want to ban this behavior?
I don't understand the above. :-( Can you please clarify your objection.
Thanks.
I don't see the interoperation pro
ity for those of who aren't participating. So, it
really is that most common of syndication archetypes: the tempest in a
teacup.
--
Robert Sayre
ility seems like total overkill.
Because this specification defines an extension to the Atom
Syndication Format [RFC4287], it is subject to the same security
consideration as defined in section 8 of that specification.
Appendix A. Acknowledgements
The authors gratefully acknowledge the feedback from the Atom
Publishing working group during the development of this
specification.
You should also acknowledge verbatim copies of text from RFC4287.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 5/3/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:
Works for me.
<http://www.alvestrand.no/pipermail/problem-statement/2003-March/000951.html>
--
Robert Sayre
]
+--++--+
100.00% | 55 |100.00% | 228920 | Total
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 5/2/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Robert Sayre <[EMAIL PROTECTED]> [2006-05-02 22:00]:
> I've been saying the same thing for weeks. I suppose it's par
> for the course to handwave about them being "strictly
> advisory", supply ci
sented in a feed is typically considered to be insignificant.
This presents a challenge when the set of entries is intended to
represent an ordered or ranked list. This document specifies an
extension...
Seems to me it's pretty darn similar.
--
Robert Sayre
e to sanctimoniously scold me for making
the suggestion, and then to adopt it with cosmetic changes.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 5/2/06, James M Snell <[EMAIL PROTECTED]> wrote:
Aristotle, I appreciate the intention, but please don't bother. It is
painfully clear that Robert has no intention of adding anything of any
real value to the discussion.
???
--
Robert Sayre
amping such things.
You mean there should be a formal agreed-on statement of what an
I-D is supposed to achieve before the process starts? If that is
what you mean: yes, that is definitely a fine idea.
And WG chairs, etc, etc.
--
Robert Sayre
On 5/1/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Robert Sayre <[EMAIL PROTECTED]> [2006-05-02 03:50]:
> especially when changes requested by the community are met with
> hostility and channel flooding.
Did this happen in more cases than the one I'm aware of?
Yes.
em. It also turns the WG into a factor in silly vendor sports,
which damages WG and IETF credibility.
--
Robert Sayre
, I just don't know what I would
do with a group of those figures, or why it's even needed.
>
> > b. Drop thr:count and thr:when from the spec.
+ 0.5. thr:when seems pretty useless.
>
> > d. Create a supplemental extension element
+1.
Robert Sayre
this reason, we kept the normalized format as close the most
> commonly
> used format (RSS 2.0) as possible, with extensions where necessary to keep
> the spirit of
> the Atom 1.0 format intact.
Works for me.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
ore substantial than essentially unused Java open source
projects. But that's not what matters, right?
There are only three significant implementers here. Microsoft,
Mozilla, and Apple. But, I think it's very important to consider the
responses of every WG member, don't you? We clearly do
On 1/24/06, James M Snell <[EMAIL PROTECTED]> wrote:
> Thoughts?
Less email. More code. Looks completely useless to me.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 1/21/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
>
>
> So let's change the application/atom+xml media type to add parameters to it
Why? There's no code that needs it. More code, less email.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 1/19/06, Robert Sayre <[EMAIL PROTECTED]> wrote:
>
> But, I could be in the minority. Which WG members think we should work
> on exciting new HTML link relations?
>
Wow. Nobody.
Phil, could we get a new rev of the Autodiscovery I-D?
--
Robert Sayre
"I would have w
m, and
they can go code it. There are lots of open source browsers.
But, I could be in the minority. Which WG members think we should work
on exciting new HTML link relations?
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 1/19/06, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> On 20/1/06 12:12 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>
> > It's not a "problem". It works now, and no one is going to run out and
> > change the running code. If someo
to run out and
change the running code. If someone did do "alternate entry", I can
see implementations getting patches to ignore those. In fact, you
don't even need a spec to help. Just start doing it. If it becomes
common, there will be patches.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
thout a new rel value.
> It doesn't rule out continuing to use
> "alternate" for those cases where the feed is actually an alternate to the
> current document.
I am lie-down-in-the-road opposed to PaceDifferentRelValue.
Interesting idea. I suggest someone write a Diffe
; "alternate" alone to die down before any aggregator developer would
> consider following along and ignoring non-"feed"s.
First person to need the feature has to spec "alternate entry" instead
of making everyone change to "alternate feed". Not it!
--
Ro
hat
implementations do pretty well. We haven't been able to come to
consensus on additional features, so I suggest we're done.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
nd be done?
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
o accomplish here.
You found a way to make a valid Atom feed that's useless. There are
lots of ways to do that.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
expect many aggregators
to support it. It is, however, accurately labeled.
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
On 12/1/05, Robert Sayre <[EMAIL PROTECTED]> wrote:
> On 12/1/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> > If it
> > turns out that that PaceFeedsNotCollections was not included in what Tim
> > was referring to by "introspection via feeds/links&
On 12/1/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> If it
> turns out that that PaceFeedsNotCollections was not included in what Tim
> was referring to by "introspection via feeds/links", then I'll move this
> one back too.
PaceFeedsNotCollections has nothing to d
On 11/30/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > I noticed you moved PaceFeedsNotCollections and PaceSimpleIntroduction
> > into the Closed section.
>
> http://www.imc.org/atom-protocol/mail-archive/msg03545.html
>
> And, unless I
d PaceFeedsNotCollections and PaceSimpleIntroduction
into the Closed section. That certainly seems reasonable to me, since
they received opposition and little support. However, the record of
their transition needs to be documented on the mailing list by the
secretary or chairs.
thanks!
--
Robert S
r just the current snapshot of
> results (and at a single instant in time it will get the same set of
> entries in either case).
I don't see how Mark's definitions prevent this. +1 to all of them.
For one thing, I have hard time imagining how the proposed definitions
could ever be *wrong*.
Robert Sayre
On 10/22/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Ok, works very well I think.
ref? Can we please ditch the pseudo-RDF garbage? Leave an idea alone
for two seconds...
Robert Sayre
27; or 'prev', those uses could conflict.
...
> This is why I'm leaning towards "prev-archive".
OK. 'prev-archive' is fine. Let's throw it against the wall see if it
sticks. No amount of atom-syntax traffic is going to resolve this.
We'll see if it turns out to be useful.
Robert Sayre
On 10/18/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> On 19/10/05 5:38 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>
> > I already have code that uses "next" for this. Why do we want to change it?
>
> Why did you choose "next&q
On 10/18/05, Antone Roundy <[EMAIL PROTECTED]> wrote:
> -3 to being that generic.
That's a very large negative number. Can you explain how your version
will me write software I otherwise couldn't?
Robert Sayre
haracterises the nature of the feed that's being linked to.
I understand that. I don't understand how that enables a new feature
or easier interoperation. In otherwords, the rationale for the
definition seems circular to me.
Robert Sayre
y one feed is making assertions about the
stability of another, when your draft provides explicit signals for
this.
2.) I still don't see how this helps me write a client.
3.) I don't think the notion of "fixed section" is helpful.
is good, that means "don't subscribe"... I get that.
Robert Sayre
On 10/18/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
>
> On 18/10/2005, at 11:38 AM, Robert Sayre wrote:
>
> >> OK, well, I'm not terribly fussed by who registers them, but they
> >> need to be carefully defined, and it wasn't at all clear
ion on what's needed here.
> Considering that there's a need for them sooner rather than later,
> would you have a problem with registering the link relations (as
> discussed in a separate thread) separately, before APP is done? If
> so, why?
No objection.
Robert Sayre
list was that we would
align with Amazon OpenSearch. In any case, I think it would be unwise
for the IETF to duplicate APP navigation.
Robert Sayre
blog's feed, dear reader), in the hopes
> of
> convincing people that this is a real issue. Silence ensued, and the
> ATOMPUB WG declined my proposal.
to which Robert Sayre replied:
> Hmm. Your proposal concerned a couple link relations, right? Those would be
> easy to add to the format
are saying silly things... why did you bother?
Robert Sayre
tom_api>
<http://www.typepad.com/t/atom/weblog/blog_id={blogid}> points to the
20 newest entries. There's a link rel="next" in there that points to
the next 20 entries.
Robert Sayre
.
Mmm. I think 'prev-archive' means exactly the same thing that 'next'
does in the feeds you're describing, and people will certainly use it
in ways that don't reflect whatever you lay out in the spec. They will
look at a feed, and think "oh, I use prev-archive to get the next 10".
I know for a fact that other feeds So, now we have two ways to say the
same thing -- The Tower of Babel problem.
http://tantek.com/log/2005/07.html#towerofbabelproblem
Robert Sayre
x.atom
'prev-archive' is more specific, and I think that's a bad thing. It
seems to introduce tower of babel problems.
Robert Sayre
tp://diveintomark.org/xml/2004/03/index.atom
Works for me. Can anyone tell us about problems this causes for their software?
Robert Sayre
e-ground. There's no reason to
specify these things in Mark's draft. If they prove useful in
implementations, they can be layered on the existing specs.
Mark has his next/prev turned around, IMHO. link rel=next should go
deeper into the past. Think of how you would write a SQL query with a
limit clause.
Robert Sayre
e, and I will go right ahead and implement
the three link relations I need in my Atom implementations: next,
prev, and profile.
Robert Sayre
that content (the
> generic term) might have a language associated with it.
What's the R in URI stand for? :)
> >and "the" implies a single language - there may be more than one.
>
> That's true. And it matches the XML 1.0 spec exactly.
I don't understand the second issue being raised here. Could someone try again?
Robert Sayre
stable, and therefore rightly excluded from the spec. I don't see
what harm the proposed extension could do, but it doesn't sound like
something I would implement. What's the benefit?
Robert Sayre
<http://tantek.com/log/posts.atom> and it worked fine.
Robert Sayre
de anything about that link
> relation; it was removed.
No, but Amazon OpenSearch has been threatening to register it, FWIW. :)
Robert Sayre
't really see how it could be a "best practice". Shame on Media
RSS.
I support draft-snell-atompub-feed-expires-04.txt moving to Proposed Standard.
(FYI-- silence does not mean consent during a last call. Movement onto
the standards track requires on-the-record comments supporting the
draft... AFAIK).
Robert Sayre
say anything about it, but most
other folks did, and I see it more as a fact of life than something
that could be cleared up with a formal model. There will always be
some new extension getting wedged in the search sequence. Which
reminds me, I should write a patch for iTunesRSS.
Robert Sayre
should make no assumptions.
>
> The crux of the question is: what happens when an extension that does
> not specify the scope appears at the feed level?
I'm not sure why this question is interesting. What sort of
application would need to know?
Robert Sayre
Anyone seen it or know where it will be found?
Robert Sayre
uld keep the extension text as it was entered.
> I suggested writing the next tag like this:
>
> http://purl.org/syndication/history/1.0/next"; href="./
> archives/archive1.atom">
That's what I would do, too. Not my spec, though. Mainly so I could
put a title in that said "Entries from August" or whatever.
Robert Sayre
no base URI itself,
the one from the entry applies, so you can still find it if you think
you need it later.
Robert Sayre
r data. Yet you are now wishing
> to put in relative references that have complex semantics
> not completely understandable without having the original context of
> the document they appear in.
Lots of extensions will be like this. What's one itunes extenstion
without the others? :)
In summary, I agree with Mark.
Robert Sayre
pens in this
hypothetical situation:
http://www.tbray.org/ongoing/hubble60.jpg";>
http://www.tbray.org/ongoing/hubble60.jpg"; />
Robert Sayre
On 8/15/05, Mark Nottingham <[EMAIL PROTECTED]> wrote:
> On 15/08/2005, at 4:28 PM, Robert Sayre wrote:
> > Why is it desirable to promote mulitple syndication formats?
> > Practically any RSS2 extension would be ok in Atom, and any Atom
> > element would be legal in
camp, though I do despise RDF-promises and RDF-lessons
offered instead of RDF-benefits and RDF-running-code).
Robert Sayre
On 8/15/05, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
>
> * Robert Sayre <[EMAIL PROTECTED]> [2005-08-15 19:05]:
> > The implementors of Internet Explorer and Mozilla agree with
> > Sam.
> >
> > http://www.franklinmint.fm/2005/08/15/base.html
>
>
the element, otherwise links can change
> meaning when you XInclude them in another document.
The implementors of Internet Explorer and Mozilla agree with Sam.
http://www.franklinmint.fm/2005/08/15/base.html
Robert Sayre
(the case in which it is recommended) have to
read the real spec.
Robert Sayre
On 8/12/05, Martin Duerst <[EMAIL PROTECTED]> wrote:
>
> +1, including the 'MUST NOT' suggestion.
+1.
Robert Sayre
strongly opposed to adding anything like
you're suggesting. Tim and I agree that the current text is
sufficient. There's a word for that.
Robert Sayre
nd of situation you run into
with syndication formats, and it should go in the implementation
guide.
Robert Sayre
or where they
will be deployed. You're suggesting adding implementation advice,
since the content of a simple extension element is not defined as a
URI reference. By your logic, we have to explicitly clarify that
atom:updated is not subject to xml:base processing. Sorry, I strongly
disagree.
Robert Sayre
they will. Relative references are fragile, and people
understand why they break. None of the other pros for this capability
are affected.
Robert Sayre
d elements containing text, leading and
trailing whitespace is considered significant.
I give a big +1 to either option.
Robert Sayre
table.
Paul, Tim, and I have all proposed text. All of them communicate the
reality, and they would all do the job. Graham +1ed Sam's idea, but
there was no spec text there. Mnot has pointed out we should write
something, because of the BCP, so let's just write something, like
now.
Robert Sayre
Robert Sayre
ases. I don't really care how they are
supported (MAY, SHOULD, MUST...), because it doesn't matter. We do
need to write something that lets the feed validator warn people about
it, but actually trying to enforce a MUST-level requirement here seems
like pissing into the wind.
Robert Sayre
is find a decent serialization
library. The lazy thing for publishers to do is concatenate strings in
their loosely-typed language of choice.
Robert Sayre
don't want to talk about it. I slightly prefer
documenting and allowing what the world's PHP scripts have been
observed to produce, but either way is fine. BTW, my proposed text was
taken from HTML 4.01.
Robert Sayre
that? That discourages sloppy feed generation,
while acknowledging what Atom Processors actually do (yes, already. we
don't actually have a choice).
Robert Sayre
On 8/2/05, Graham <[EMAIL PROTECTED]> wrote:
> On 2 Aug 2005, at 9:07 pm, Robert Sayre wrote:
>
> > For me, the most disturbing aspect of this debate is that any
> > resolution will provide very, very little interoperability gain.
>
> Agreed. All we need to do
think we're off in
the weeds. That said, I certainly wouldn't object to any text warning
people not to do it, or explicitly mentioning that you have to call
the equivalent of String.trim().
Robert Sayre
http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.html
http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt
Robert Sayre
dev/200309/msg00434.html
I'm not an expert, but I verifed that it was happening here with Jing
and nxml-mode.
Robert Sayre
ading and trailing
whitespace. Atom Processors will do the same, so we should fix it.
"Comparison operations MUST be based solely on the IRI character
strings", and the URI specs have always suggested that you should
strip leading and trailing space.
Robert Sayre
to me, but I recall squawking about this.
> Which would enable the text in appendix B to simply state:
>
> The RelaxNG grammar explicitly excludes elements in the Atom
> namespace which are not defined in this revision of the specification.
Sounds good.
Robert Sayre
Sigh, I can't do anything right today.
On 7/31/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> On 1/8/05 9:34 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
>
> > If anyone objects to any of the *new
> > text*, please speak up.
>
> spel
On 7/31/05, Graham <[EMAIL PROTECTED]> wrote:
> And what is this mysterious "source attribute"?
> I presume you mean
> "src", but it is not expanded to "source" anywhere else in the document.
Oops. Thanks.
Robert Sayre
Sounds good.
On 7/31/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > The documents linked below represent the editors' efforts to resolve
> > our single IESG objection, and to fix a few spec bugs that have been
> > brought up in the past few we
ompub-format-11-from-10.diff.html
txt:
http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.txt
html:
http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.html
Robert Sayre
the problem.
> The problem is still "what should happen when the http response is X and
> the code in the XML is 'Y'?" You only need one value for each to reduce
> robustness.
There's no special version of HTML for error pages. Let's use an Atom
Entry Document.
Robert Sayre
with the body of a non-200 response (I think).
The same problem exists in the protocol. Right now, you'll see
typepad.com return a document that looks like this:
some text...
We could have them return Atom entries instead. *shrugs
Robert Sayre
the charter.
That seems like self-perpetuating bureaucracy.
Another way of putting it would be that, absent new participants, I
favor completing the autodiscovery and protocol drafts and closing the
WG.
Robert Sayre
retty high, and the damage/good of such an effort is unkown. Each
standards organization's process is a known quantity. I would jump
first if I were you.
Robert Sayre
have to pick something to propose
a *new* feature), and leave field names up to the editors until WG
last call.
Robert Sayre
On 7/16/05, Danny Ayers <[EMAIL PROTECTED]> wrote:
> How do you even *do* a podcast in Atom? (This is kind-of what I'm
> trying to get at ;-)
> What clients support podcasts in Atom?
NetNewsWire supports it.
Robert Sayre
osted by yours truly, but I'm not attached to it. If
someone wants to improve it, take it over, host it in a secure
facility, etc I'd be happy to transfer it or share responsibility.
Contact me offline if interested.
Robert Sayre
e going to use them. Accurate once
again.
As for Alex Bosworth's post, a commenter said "This post is rubbish
and way off base." I'm inclined to agree. Seems like a publicity
stunt.
Robert Sayre
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F
:)
Robert Sayre
On 7/15/05, Graham <[EMAIL PROTECTED]> wrote:
>
> On 15 Jul 2005, at 4:56 pm, Walter Underwood wrote:
>
> > Do we have a list of who is implementing it? That cou
Absolutely.
Robert Sayre
On 7/15/05, Henry Story <[EMAIL PROTECTED]> wrote:
>
> Sorry. It looks like there is a final namespace:
>
> http://www.w3.org/2005/Atom
>
> Is that correct?
>
> Henry
>
> On 15 Jul 2005, at 20:06, Henry Story wrote:
> >
http://atompub.org/
Robert Sayre
On 7/15/05, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote:
>
> On Fri, 15 Jul 2005 10:32:29 +0200, Anne van Kesteren
> <[EMAIL PROTECTED]> wrote:
>
> > (Except for the namespace that is. Ouch!)
>
> Yea, that was a bit awkward.
http://www.w3.org/2005/Atom/BiKeShEd?
(yay!)
Robert Sayre
101 - 200 of 708 matches
Mail list logo
