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.
When I read terms like
, 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
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.
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/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 written a shorter letter, but I
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.
?
--
Robert Sayre
I would have written a shorter letter, but I did not have the time.
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.
aggregator developer would
consider following along and ignoring non-feeds.
First person to need the feature has to spec alternate entry instead
of making everyone change to alternate feed. Not it!
--
Robert Sayre
I would have written a shorter letter, but I did not have the time.
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 DifferentSpec.
--
Robert Sayre
I would have written a shorter letter
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.
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.
was undeniably supported by the spec.
I guess you can make it just as hard if you really try. The typed
variants of the content element are an extension point. You could put
application/xaml+xml in there, but I wouldn't expect many aggregators
to support it. It is, however, accurately labeled.
--
Robert
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.
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, then I'll move this
one back too.
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 Sayre
I would have written a shorter
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 misinterpreted, both Paul and Tim confirmed via
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, x:profile ref={uri} / works very well I think.
ref? Can we please ditch the pseudo-RDF garbage? Leave an idea alone
for two seconds...
Robert Sayre
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
.
prev-archive (or maybe prev-entries?) is starting to look better, as
is fh:prev/.
Hogwash. Do not reinvent the AtomAPI. Posting on atom-syntax and then
claiming your way is the right way after all because people are
arguing and some folks are saying silly things... why did you bother?
Robert
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 at anytime, and... Blogger and 6A have both asked
for
similar functionality
align with Amazon OpenSearch. In any case, I think it would be unwise
for the IETF to duplicate APP navigation.
Robert Sayre
.
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
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 that the
OpenSearch document did that.
I think maybe we
.) I still don't see how this helps me write a client.
3.) I don't think the notion of fixed section is helpful.
fh:archive is good, that means don't subscribe... I get that.
Robert Sayre
that enables a new feature
or easier interoperation. In otherwords, the rationale for the
definition seems circular to me.
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?
Because that is what's already been deployed and what my software uses.
Robert
about problems this causes for their software?
Robert Sayre
, and I think that's a bad thing. It
seems to introduce tower of babel problems.
Robert Sayre
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
newest entries. There's a link rel=next in there that points to
the next 20 entries.
Robert Sayre
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
the three link relations I need in my Atom implementations: next,
prev, and profile.
Robert Sayre
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
and it worked fine.
Robert Sayre
.
No, but Amazon OpenSearch has been threatening to register it, FWIW. :)
Robert Sayre
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
, 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
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
of extensions will be like this. What's one itunes extenstion
without the others? :)
In summary, I agree with Mark.
Robert Sayre
suggested writing the next tag like this:
link type=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
it is recommended) have to
read the real spec.
Robert Sayre
in another document.
The implementors of Internet Explorer and Mozilla agree with Sam.
http://www.franklinmint.fm/2005/08/15/base.html
Robert Sayre
, and people
understand why they break. None of the other pros for this capability
are affected.
Robert Sayre
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
into
with syndication formats, and it should go in the implementation
guide.
Robert Sayre
containing text, leading and
trailing whitespace is considered significant.
I give a big +1 to either option.
Robert Sayre
,
while acknowledging what Atom Processors actually do (yes, already. we
don't actually have a choice).
Robert Sayre
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
. 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
not an expert, but I verifed that it was happening here with Jing
and nxml-mode.
Robert Sayre
://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
of String.trim().
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 is decide one way or the other what
.
Sounds OK 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
-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
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 weeks. If anyone objects to any of the *new
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
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.
spello:
s/forwards-compatable/forwards-compatible/
e.
response (I think).
The same problem exists in the protocol. Right now, you'll see
typepad.com return a document that looks like this:
errorsome text.../error
We could have them return Atom entries instead. *shrugs
Robert Sayre
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
organization's process is a known quantity. I would jump
first if I were you.
Robert Sayre
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
inclined to agree. Seems like a publicity
stunt.
Robert Sayre
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
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
), and leave field names up to the editors until WG
last call.
Robert Sayre
http://atompub.org/
Robert Sayre
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:
It would be easy to add atom to BlogEd, though I really
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 could be used
here:
http://www.imc.org/atom-syntax/mail-archive/msg14423.html
Sorry you didn't get direct feedback. :/
Robert Sayre
in smaller, more bandwidth-efficient feeds.
Here are two uses:
1.) Calculate a signature for each entry once, but vary the number of
entries in a feed.
2.) Pass through a signature received via Atom Protocol.
Robert Sayre
On 6/18/05, Joe Gregorio [EMAIL PROTECTED] wrote:
On 6/17/05, Sam Ruby [EMAIL PROTECTED] wrote:
P.S. Why is this on atom-sytax? Is there a concrete proposal we are
talking about here? Is there likely to be?
Were you expecting [atom-syntax] to vanish in a puff of smoke
once we have a
up the crawl,
with a bunch of rhetoric surrounding it. Maybe I'm just cynical.
Robert Sayre
On 5/25/05, Tim Bray [EMAIL PROTECTED] wrote:
Have I missed any? Yes, there has been high-volume debate on several
other issues; but have there been any other outcomes where we can
reasonably claim consensus exists?
Not in my opinion. Looks good to me.
Robert Sayre
extension.
Remove is an empty element that.
http://www.imc.org/atom-syntax/mail-archive/msg14365.html
Robert Sayre
On 5/24/05, Graham [EMAIL PROTECTED] wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
On 5/24/05, Graham [EMAIL PROTECTED] wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
don't see a problem here. You just don't understand that
some extension content has its role defined by the spec ahead of time,
and some doesn't (undefined). I don't see any reason to revisit
this.
bye,
Robert Sayre
On 5/24/05, Graham [EMAIL PROTECTED] wrote:
On 24 May 2005, at 5:44 pm, Robert Sayre wrote:
FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html
But if I encounter a link element that's weirdly non-empty and
contains markup from some other namespace, that's the kind
anyone propose it.
Robert Sayre
On 5/23/05, Graham [EMAIL PROTECTED] wrote:
On 23 May 2005, at 12:15 pm, Robert Sayre wrote:
-1 to this part. Why would you bar it? There is no right answer, so
just let it be looser.
Because we have to have this line:
Within the atom:author and atom:contributor elements
On 5/23/05, Anne van Kesteren [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
What happens when it does contain child elements? I think we should
define that for interoperability. (See HTML for what happens when
you don't.) This question also applies to the next section.
No, that's broken
On 5/23/05, Graham [EMAIL PROTECTED] wrote:
On 23 May 2005, at 12:28 pm, Robert Sayre wrote:
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.
With the line in place, generating a basic byline is as simple
On 5/23/05, Graham [EMAIL PROTECTED] wrote:
On 23 May 2005, at 1:09 pm, Robert Sayre wrote:
Fully disagree. Try a record album by the Rolling Stones or
Grandmaster Flash and The Furious 5. OK to list the band members as
contributors? Definitely.
Maybe there's a minor bug
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, will be implemented in an extension, not in Atom.
Is your name
' will
obviate the need for fuzzy logic and constitute a coherent 'model' to
program against. YMMV.
Robert Sayre
On 5/23/05, Dan Brickley [EMAIL PROTECTED] wrote:
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).
Why would that be good?
Robert Sayre
and be done with it.
Robert Sayre
as a
contributor. But, it would make sense to list her as a contributor as
well.
Robert Sayre
On 5/23/05, Graham [EMAIL PROTECTED] wrote:
On 23 May 2005, at 4:52 pm, Robert Sayre wrote:
Exactly. It's extremely easy to think of cases that don't fit the
model proposed. Consider the Huffington Post, where the feed might
list Arianna Huffington as the author, and everybody else
http://www.intertwingly.net/wiki/pie/PaceAuthorContributor
== Abstract ==
Allow multiple authors.
== Status ==
Open
== Rationale ==
The current draft only allows one atom:author per entry, meaning either:
- All authors of a document have to be shoehorned into that atom:author element
- One
: Address Extensibility.
YES. Perfectly addressed.
Requirement 12: Identify deprecated features.
N/A. None.
Requirement 13: Define how each class of product handles each
deprecated feature.
N/A. None.
Robert Sayre
, which requires an alternate link.
Robert Sayre
be an atom:feed element, and those have required
elements. The RNC also requires atom:title and atom:updated, etc. I
guess we could add All required feed metadata elements MUST be
present. OK?
Robert Sayre
On 5/22/05, Graham [EMAIL PROTECTED] wrote:
On 21 May 2005, at 4:23 pm, Robert Sayre wrote:
What document is impossible to express with the current syntax?
At this point, it's impossible to express anything, since several of
us are no longer sure what the meanings of atom:author
On 5/22/05, Graham [EMAIL PROTECTED] wrote:
On 22 May 2005, at 1:09 pm, Robert Sayre wrote:
No longer sure? I suggest you never will be, since the meanings of the
elements are right there in the draft, as is the cardinality. It seems
reasonable to conclude you people can't read
, author metadata, digital signatures, and the location at
which one night retrieve the feed.
Robert Sayre
101 - 200 of 514 matches
Mail list logo
