Well I share the concern because while developing amplee I ran into
issues like that. My conclusion was to apply HTTP error handling where I
could and where it made sense and leave the rest to the application
developer using amplee.
For instance return one of the 4xx error code when I meeting
I'm the chairman of the RSS Advisory Board, which has
published our first autodiscovery specification [1].
I'd like to participate in the drafting of Atom's
effort in this area with the goal of making it
possible for publishers to support autodiscovery in
the same manner regardless of syndication
http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational
#pragma section-numbers off
== Abstract ==
Move Autodiscovery forward as an Informational RFC
== Status ==
Proposed
== Rationale ==
At this point there seems to be very little reason for the autodiscovery
draft to be
http://www.intertwingly.net/wiki/pie/PaceRestrictRelValuesForAutodiscovery
http://www.intertwingly.net/wiki/pie/PaceRestrictTypeValuesForAutodiscovery
While I definitely understand the rationale behind this, it's unlikely
that the spec will actually lead to any change in behavior for the
various
James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational
Move Autodiscovery forward as an Informational RFC
But if it were published as an informational RFC, what purpose would it
serve?
I intend to post a much more substantial review of the current
On Tue, 28 Nov 2006 17:37:03 +0100, James M Snell [EMAIL PROTECTED]
wrote:
== Proposal ==
Change the status of the autodiscovery draft to Informational.
+1
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Lachlan Hunt wrote:
[snip]
Move Autodiscovery forward as an Informational RFC
But if it were published as an informational RFC, what purpose would it
serve?
To document best practice as it relates specifically to syndication
feeds. For example, HTML5 says nothing about whether the
On 28 Nov 2006, at 16:37, James M Snell wrote:
== Proposal ==
Change the status of the autodiscovery draft to Informational.
+1
There's really no need for it to be a standard, as it's widely
implemented in a common way.
- Geoffrey Sneddon
James M Snell wrote:
Lachlan Hunt wrote:
[snip]
Move Autodiscovery forward as an Informational RFC
But if it were published as an informational RFC, what purpose would it
serve?
To document best practice as it relates specifically to syndication
feeds.
The draft
Robert Sayre wrote:
[snip]
To document best practice as it relates specifically to syndication
feeds.
The draft makes several requirements. That's not documenting best
practice.
[snip]
If the doc is changed to informative, the normative requirements in the
draft would need to be relaxed
James M Snell wrote:
I didn't write the doc so please don't complain to me about what's in
there. If there is something that needs to be changed write up a pace.
Uh, no. I don't think you should write it at all, and I resent having to
waste my time following this completely redundant
I do believe that participation in this discussion is optional, as is
choosing whether or not to support any particular IETF draft
(informational or otherwise) so there is absolutely no need (or desire)
for you to waste your time here. Your opinion that the document is
unnecessary has been
On 24 Nov 2006, at 01:44, Henri Sivonen wrote:
On Nov 23, 2006, at 22:42, Henry Story wrote:
This is very nice, in that it opens up the possibility of placing
good RDF descriptions of these links at the http://www.iana.org/
assignments/relation/,
How could new link relations be described
James M Snell wrote:
I do believe that participation in this discussion is optional, as is
choosing whether or not to support any particular IETF draft
(informational or otherwise) so there is absolutely no need (or desire)
for you to waste your time here.
Nonsense. You know very well that
+0. I have no particular agenda on this other than helping to move it
forward if that's what folks want. I will note, however, that the
overall response to PaceResurrectAutodiscovery was positive and there
seemed (to me at least) to be interest in at least discussing the future
of the draft. So
http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery
Definite -1 on this one. Buggy implementations just need to be fixed.
Writing specs to bugs is silly at best.
- James
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
2006/11/28, Robert Sayre:
The WHAT-WG text is fine.
-1
For various reasons, including:
http://www.imc.org/atom-syntax/mail-archive/msg19100.html
http://www.imc.org/atom-syntax/mail-archive/msg19107.html
--
Thomas Broyer
2006/11/28, Robert Sayre:
Nonsense. You know very well that projects I work on will get bug
reports on standards compliance if you change something. So, yes, I do
have to waste my time here. Since I maintain autodiscovery code people
actually use, you'd think my opinion would count for
Edward O'Connor wrote:
I am worried that there are three simultaneous efforts to spec out feed
autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally
this stuff would get specced just once. WHAT WG seems like a neutral
ground, syndication-format wise, so perhaps they're best
Robert Sayre wrote:
Edward O'Connor wrote:
I am worried that there are three simultaneous efforts to spec out feed
autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally
this stuff would get specced just once. WHAT WG seems like a neutral
ground, syndication-format wise,
James M Snell wrote:
http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery
Definite -1 on this one. Buggy implementations just need to be fixed.
Writing specs to bugs is silly at best.
The link element is specified by HTML4/5.
-Rob
James M Snell wrote:
Heh.. I probably should not have been taking a drink when I read this
last sentence :-). You do know that we're talking about the
*syndication community* right?
Actually, it's an HTML issue, so I don't see why the RSS Board or the
Atom list or any incarnation of the
Sylvain Hellegouarch wrote:
If autodiscovery is only a browser feature then indeed it has nothing to
do here. But is it only meant for browsers?
Browsers are surely the primary target, but bots and other HTML UAs make
use of it. Both uses are covered by the people working on HTML, in the
Lachlan Hunt wrote:
http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss
Like the Atom Autodiscovery draft, this spec serves no purpose.
Autodiscovery is being defined in the HTML5 spec where it belongs, with
both the alternate
Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established. What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.
- James
Robert Sayre
If the Atom/RSS autodiscovery spec describes how to
work with the link element to achieve feed
autodiscovery in browsers and other clients, isn't it
an application of (X)HTML rather than an attempt to
specify (X)HTML?
My thinking was that we're accomplishing a task
similar to the creators of the
James M Snell wrote:
Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established. What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.
James M Snell wrote:
Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established. What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.
On Nov 28, 2006, at 22:11, Edward O'Connor wrote:
WHAT WG seems like a neutral ground, syndication-format wise, so
perhaps they're best positioned to spec feed autodiscovery in a way
that makes everybody happy.
+1 for leaving speccing this to the WHATWG.
--
Henri Sivonen
[EMAIL
Ted,
Please correct me if I get any of this incorrect, but for the sake of
the discussion I wanted to summarize the HTML5 [1][2] definitions here:
The following three links are equivalent to one another and specify that
the linked feed is an alternate representation of the page.
link
On 28 Nov 2006, at 21:01, Robert Sayre wrote:
James M Snell wrote:
http://www.intertwingly.net/wiki/pie/
PaceRecommendFullURIsForAutodiscovery
Definite -1 on this one. Buggy implementations just need to be
fixed.
Writing specs to bugs is silly at best.
The link element is specified
Rogers Cadenhead wrote:
My thinking was that we're accomplishing a task
similar to the creators of the Robots Exclusion meta
tag [1] -- put X values in element Y to achieve effect
Z.
Hmm, have to disagree. The behavior is already well-documented, so this
isn't accomplishing much. This
--- Robert Sayre [EMAIL PROTECTED] wrote:
Is there some aspect of the WHAT-WG document that
bothers you?
Not yet, aside from the notion that they've got an
incredibly ambitious goal -- spec the next
HTML/XHTML/DOM -- and I have no idea how to gauge the
likelihood they'll achieve it. Or whether
James,
Please correct me if I get any of this incorrect, but for the sake of
[...]
What I did not see in the HTML5 spec is any indication of whether the
order of link relations is significant. I'm assuming that means that
it is not. I'm also assuming that means that all alternate feed link
The problem I have with the WHAT-WG definition of the alternate and feed
relations is the unintended conflict that occurs when the alternate
representation of a page happens to be an Atom Entry Document.
The HTML5 draft says,
If the alternate keyword is used with the type attribute set
On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote:
I have no idea how to gauge the
likelihood they'll achieve it. Or whether they'll
respect current autodiscovery functionality in MSIE 7
and Firefox 2.0.
My experience is that the IETF is essentially unresponsive to backward
compatibility
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:
3. We define a new media type for Atom Entry Documents,
e.g. application/atomentry+xml
No one relies on Atom Entry alternates now, so this is the best
option. We should tack it onto the APP draft, since that will solve
issues with the
On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote:
They already know how, in general. The WHAT-WG is the place to work
out edge cases in HTML semantics.
Over the course of history, a remarkable number of different groups
have jumped up and down and said *We're* the ones defining HTML!!!
On 11/28/06, Tim Bray [EMAIL PROTECTED] wrote:
On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote:
They already know how, in general. The WHAT-WG is the place to work
out edge cases in HTML semantics.
Over the course of history, a remarkable number of different groups
have jumped up and down
At 4:56 PM -0500 11/28/06, Robert Sayre wrote:
James M Snell wrote:
Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established. What would be excellent is if you'd give others the
opportunity to weigh
At 6:16 PM -0500 11/28/06, Robert Sayre wrote:
On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote:
I have no idea how to gauge the
likelihood they'll achieve it. Or whether they'll
respect current autodiscovery functionality in MSIE 7
and Firefox 2.0.
My experience is that the IETF is
Hello,
Over on the IETF Atom Syntax mailing list we're discussing whether or
not to pursue the autodiscovery draft that had previously been put on
the table [1] or to simply point to the HTML5 work and be done with it.
While reviewing the HTML5 draft and comparing that to the Atom
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:
2. Are multiple alternate links with the same type attribute
considered to be equivalent regardless of where those links appear
in the document.
What do you mean by equivalent ?
--
Robert Sayre
* James M Snell [EMAIL PROTECTED] [2006-11-29 00:20]:
3. We define a new media type for Atom Entry Documents,
e.g. application/atomentry+xml
+1
* Robert Sayre [EMAIL PROTECTED] [2006-11-29 00:40]:
We should tack it onto the APP draft, since that will solve
issues with the accept
It has been suggested that a good meeting location might be Tied
House in Mountain View [1]. It has a back room that's like a patio
but covered and heated for dinner on either
Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec
Any preferences?
Henry Story
[1]
Sylvain Hellegouarch wrote:
I have no will to wait and see whether or not the WHATWG recommendation
will eventually be applied. If we have to wait for one or two years to
get their final document then I don't see how an informational spec
could harm the community while waiting.
Don't freak
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:
There are three possible solutions:
1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom
media type is addressed
What ambiguity? There's no ambiguity AFAICT.
But the WHAT spec does need fixing. Assuming rel=feed
Ian Hickson wrote:
[snip]
Here, while the last three are also valid feeds, it is the first one that
should be considered the default when doing auto-discovery. This isn't to
say that the feed UA should ignore the other three, or that it should only
show them if the user goes out of his
Any of those would be good for me. Be careful of the deep fried onion
rings at Tied House, though.
Henry Story wrote:
It has been suggested that a good meeting location might be Tied House
in Mountain View [1]. It has a back room that's like a patio but
covered and heated for dinner on
Hi,
This feedback is related to the autodiscovery draft.
Before reading on, I suggest anyone writing a specification of any kind
actually learn a little about how to write good conformance criteria.
http://ln.hixie.ch/?start=1140242962count=1
I do not believe it is at all useful for this
Robert Sayre wrote:
On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:
3. We define a new media type for Atom Entry Documents,
e.g. application/atomentry+xml
No one relies on Atom Entry alternates now, so this is the best
option. We should tack it onto the APP draft, since that will
52 matches
Mail list logo
