On May 23, 2006, at 12:16 PM, Tim Bray wrote:
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by
On 5/30/06, Lisa Dusseault [EMAIL PROTECTED] wrote:
At the end of the day, the marketplace will work within the
constraints of what 4287 allows; my feeling is that there are going
to be a ton of extensions that will attach unforeseen metadata at
arbitrary points with Atom documents, and
Robert Sayre wrote:
[snip]
document. In this case, it's another case of a WG member claiming
something is broken without a shred of spec text to back it up. If Tim
The exact same can be said of the argument that the use of extension
attributes is broken. There's not a shred of spec text to
On 5/30/06, James M Snell [EMAIL PROTECTED] wrote:
Robert Sayre wrote:
[snip]
document. In this case, it's another case of a WG member claiming
something is broken without a shred of spec text to back it up. If Tim
The exact same can be said of the argument that the use of extension
Tuesday, May 23, 2006, 10:31:37 PM, Tim Bray wrote:
I would say that furious debates about elements-vs-attributes have
been going on since the dawn of XML in 1998, but that would be
untrue; they've been going on since the dawn of XML's precursor SGML
in 1986. They have never led anywhere.
* Tim Bray [EMAIL PROTECTED] [2006-05-23 23:40]:
On May 20, 2006, at 8:49 AM, David Powell wrote:
Foreign attributes are bad, and are inherently less
interoperable than Extension Elements.
I would say that furious debates about elements-vs-attributes
have been going on since the dawn of
On May 17, 2006, at 12:46 PM, Byrne Reese wrote:
Speaking up:
http://www.majordojo.com/atom/
standardizing_the_atom_thread_extension.ph
p
No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.
Me too. Does something useful, does no harm, if it's broken in some
way
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of
+1. What Tim said.
- James
Tim Bray wrote:
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by
I've had a hard time following this thread, but for what its worth I
buy Tim's reasoning.
+1
On May 23, 2006, at 12:26 PM, James M Snell wrote:
+1. What Tim said.
- James
Tim Bray wrote:
On May 18, 2006, at 6:15 AM, David Powell wrote:
What I see as a problem is that reasonable
At the end of the day, the marketplace will work within the
constraints of what 4287 allows; my feeling is that there are going to
be a ton of extensions that will attach unforeseen metadata at
arbitrary points with Atom documents, and implementations that fail to
store these and make
At 8:39 PM +0100 5/23/06, Sylvain Hellegouarch wrote:
At the end of the day, the marketplace will work within the
constraints of what 4287 allows; my feeling is that there are going
to be a ton of extensions that will attach unforeseen metadata at
arbitrary points with Atom documents, and
Welcome to the messy world of standards. There might be a need for an
updated FTE RFC. On the other hand, if the market gives a big yawn,
there is probably no need to update the RFC if no one is using it. On
the third hand, it doesn't hurt to have it updated anyway; there are
lots of RFCs
On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length)
I'm going to re-organize David's argument a little and deal with one
of his last points first.
Foreign attributes are bad, and are inherently less interoperable
than Extension Elements.
I would say that furious debates
On 5/23/06, Tim Bray [EMAIL PROTECTED] wrote:
I would vociferously resist any such claim.
OTOH, there are more than a few products on the market right now that
back up just such a claim. So there's an existence proof, and most of
the APIs I've seen *do* make use simple vs. structured, but
Friday, May 19, 2006, 1:40:43 AM, Lisa Dusseault wrote:
I've been trying to understand if there's a technical problem with
the draft's chosen placement of the attributes and the best case
I've seen is that that location is technically disallowed by
RFC4287 , an assertion which is disputed
On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote:
Am I missing something in the case against the choice of location for
the metadata?
Yes. That location is going to cause interoperability problems in my
implementation, because the draft leaves too much undefined, and in
implementations who
Robert Sayre wrote:
On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote:
Am I missing something in the case against the choice of location for
the metadata?
Yes. That location is going to cause interoperability problems in my
implementation, because the draft leaves too much undefined,
On 5/19/06, James M Snell [EMAIL PROTECTED] wrote:
Other than the issue with the Microsoft implementation, which has
already been thoroughly discussed, what other interop problems are you
anticipating? A clear, non-editorialized, listing of the potential
issues and the rationale for each
The latter is, of course, not specific to FTE, but apparently is enough
of a problem to at least warrant a mention.
Thank you. This is fully appreciated.
- Sylvain
When Friendster approached Six Apart and asked for a way to keep abreast
as to the comment activity within the Friendster Blogging network
(powered by TypePad), I turned immediately to FTE.
In this implementation, there was actually no desire for Friendster to
gain access to the comments
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
That doesn't accurately state my problem with FTE. My concern is more
general
By acting as you do, we may end up in a huge amount of feeds being sent onthe wire to clients which believe the feed has actually changed in its
content when it has changed only in one meta-data value (that they willnot handle anyway).
Servers don't *have* to change the feed's Last-Modified and
By acting as you do, we may end up in a huge amount of feeds being sent
on
the wire to clients which believe the feed has actually changed in its
content when it has changed only in one meta-data value (that they will
not handle anyway).
Servers don't *have* to change the feed's
Well this is debatable because you effectively change the resource itself
and ought to update its meta-data as well (ie Last-Modified and Etag
values).
Besides, by not doing so can be even worse because an aggregator would
requests the feed, the server would respond with a 304 and the
On Thu, May 18, 2006 at 09:26:18AM +0100, Sylvain Hellegouarch wrote:
By acting as you do, we may end up in a huge amount of feeds being sent on
the wire to clients which believe the feed has actually changed in its
content when it has changed only in one meta-data value (that they will
not
It's a valid concern, but as James has been saying the problem is with
the syndication model. This isn't something that Atom (or any extension)
can solve.
I agree with you and James. This is much larger issue and this spec is not
the right place to try solving it.
Do you have any
And I am sorry for the numerous mistakes I make in my written English. *sigh*
David,
David Powell wrote:
Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
That doesn't accurately state my problem with
* James M Snell [EMAIL PROTECTED] [2006-05-18 17:40]:
My interpretation of the text and the RELAX NG definition is
that while the specification does not assign any meaning to
extensions of the link element, it is nonetheless explicitly
allowed.
Noone ever debated that.
It may have been a
Look at that giant email. Seems to me that it's a debate taking place
for no discernable reason. There's no technical reason for the
placement of the attributes, and management has made it clear that any
objections are irrelevant.
Hope that helps!
On 5/18/06, James M Snell [EMAIL PROTECTED]
* Robert Sayre [EMAIL PROTECTED] [2006-05-18 18:05]:
There's no technical reason for the placement of the
attributes,
Do you have better ideas on how to provide this information on a
per-link basis? It would help if you actually tried to suggest an
approach instead of bashing what’s there.
On May 18, 2006, at 8:10 AM, Brendan Taylor wrote:
Do you have any suggestions about how this metadata could be included
without changing the content of the feed? AFAICT the only solution
is to
not use the attributes (which aren't required, of course).
If it's in the feed document and it
* Antone Roundy [EMAIL PROTECTED] [2006-05-18 20:05]:
and in another document:
ct:comment-tracking xmlns:ct=... xmlns:atom=... ...
atom:link rel=related href=URL of the feed ... /
ct:entry ref=foo
atom:link rel=comments href=... type=...
On May 18, 2006, at 12:31 PM, A. Pagaltzis wrote:
Actually, you don’t really need another format. There’s no reason
why you couldn’t use atom:feed in place of your hypothetical
ct:comment-tracking. :-) Your ct:entry elements could almost be
atom:entry ones instead, too, except that assigning
* Antone Roundy [EMAIL PROTECTED] [2006-05-18 21:40]:
The point of the whole exercise is to create a lightweight
document for volatile metadata. If it's an atom:feed, you have
to include a lot of stuff that's not needed here--atom:title,
atom:updated, atom:author, and atom:summary or
a:f id=idoffeed a:ds=1a:e id=idofentry a:r=2a:c id=idofcomment a:r=1a:c id=idofcomment a:r=2/
/a:c/a:ea:e id=idofentry: a:r=3//a:fThe requestor sends a request for all entries and comments on those entiries since a certain date. If the date request is considered reasonable, a compact atom syntax
On May 18, 2006, at 8:56 AM, Robert Sayre wrote:
Look at that giant email. Seems to me that it's a debate taking place
for no discernable reason. There's no technical reason for the
placement of the attributes, and management has made it clear that any
objections are irrelevant.
I realize
Hello Robert,
It's not the IETF which wants to move this on on Standards Track,
it's (currently) James as an individual submitter. The IESG just
did what it does for all such requests from individuals: Put the
document out for IETF Last Call and tell the relevant mailing lists
about it.
Now
[snip]
- We're talking about adding machine-parsable data that would be
invisible to readers of the post content
I don't know. The specification says nothing about that. Presumably,
the implementers that have already deployed know what they are for.
Machine-parseable data that may or
* Eric Scheid [EMAIL PROTECTED] [2006-05-17 14:25]:
would this mean this is possible:
entry
link rel=replies thr:count=5 xml:lang=en href=1 /
link rel=replies thr:count=1 xml:lang=fr href=1 /
...
/entry
You mean `hreflang`, not `xml:lang`, right?
I have to say at first blush
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
You mean `hreflang`, not `xml:lang`, right?
oops, yes.
I have to say at first blush I don¹t see why it should not work,
so I find your thought experiment quite amusing.
:-)
Sylvain Hellegouarch wrote:
[snip]
If a feed containg FTE information is meant to be handled by machines
only, then those values are not precise enough to be use (but I'd be happy
to gearing about them though). If those values are to be presented to
users, they are also not precise to have
I have no idea what you mean by not precise enough to be used. What
makes them imprecise?
The very fact they don't represent a state that can be trusted. As the
spec says they are not the true value but the true value at one given
time.
Look at just about piece of blogging software that
The ref attribute is the unique identifier of the resource being
responded to. It doesn't make make sense to respond to a Feed.
By the way, don't get me wrong. I am really looking forward to the FTE
replies element but not its attributes which are just useless and counter
productive to my
Sylvain Hellegouarch wrote:
I have no idea what you mean by not precise enough to be used. What
makes them imprecise?
The very fact they don't represent a state that can be trusted. As the
spec says they are not the true value but the true value at one given
time.
The values are no
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
entry
link rel=replies thr:count=5 xml:lang=en href=1 /
link rel=replies thr:count=1 xml:lang=fr href=1 /
...
/entry
You mean `hreflang`, not `xml:lang`, right?
I also meant there to be different hrefs too :-(
entry
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
Apache would respond: well yes the file has
changed on the disk so here it is when in fact the content of the feed
has only changed for the number of comments of an entry.
so?
we have atom:updated to help aggregators detect
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I have to say at first blush I don¹t see why it should not work,
so I find your thought experiment quite amusing.
this should be amusing too:
entry
link rel=replies thr:count=5 href=1 title=trackbacks! /
link rel=replies
Yes. This is possible. What I'm not sure about is whether amusing is
good or bad. What point are you trying to make exactly?
- James
Eric Scheid wrote:
On 17/5/06 10:47 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I have to say at first blush I don¹t see why it should not work,
so I find your
Can't you just ignore them then? The feed update / last-modified issue
is not isolated to the use of thr:when and thr:count. As I mentioned in
another note, you end up with the exact same problem when folks use the
slash:comments element but no one seems to mind that. This problem is
not
On 18/5/06 1:36 AM, Sylvain Hellegouarch [EMAIL PROTECTED] wrote:
Apache would respond: well yes the file has
changed on the disk so here it is when in fact the content of the feed
has only changed for the number of comments of an entry.
so?
we have atom:updated to help aggregators
HTTP provides a possible solution to this in the form of a weak entity
tag. Also, Feed delta encoding could be leveraged to further mitigate
the potential issues.
ETag are not reliable without If-Modified-Since header and they are not as
wide spreaded.
I would suspect that you
Sylvain Hellegouarch wrote:
[snip]
I would suspect that you currently have the same problems with folks
that use the highly popular slash:comments RSS extension. FTE is not
introducing any new problems, nor is it seeking to fix existing problems
in the feed syndication model.
This is
* Sylvain Hellegouarch [EMAIL PROTECTED] [2006-05-17 20:10]:
However, if I'm an aggregator I don't need the thr:count and
thr:when because I will find those information anyway with the
following process:
Consider the situation where a weblog only has a single global
comments feed – which I
Sylvain Hellegouarch wrote:
[snip]
What else, in your opinion makes them useless and counter productive?
I'm seriously asking because I really don't see it.
Well to me there is no need to include, or specify, information that
cannot be found otherwise already.
Do you feel the same way
:15 PM
To: atom-syntax
Subject: Feed Thread in Last Call
Hey all,
I'm happy to announce that the Feed Thread extension (draft -10) [1] has
entered Last Call. [2]
The thr:count and thr:when extension attributes are back in Draft -10
following the recent on-list discussion and post by Tim Bray
Sylvain Hellegouarch wrote:
However, if I'm an aggregator I don't need the thr:count and thr:when
because I will find those information anyway with the following process:
That's certainly one way of doing things, but not the only way. I'm fairly
sure there are existing clients that rely on
Sylvain Hellegouarch wrote:
Can't you just ignore them then? The feed update / last-modified issue
is not isolated to the use of thr:when and thr:count. As I mentioned in
another note, you end up with the exact same problem when folks use the
slash:comments element but no one
If you don't like these attributes, that's fine - nobody is forcing you to
use them. But don't assume that everyone wants to do things the same way
as
you. Don't try and prevent people from doing something different to you
just
because you personally don't like their choice.
The problem
This boils down to an implementation choice. The thr attributes provide
a way for UI's to display something before fetching the feed, which is
often useful for an individual to decide whether or not it is even
worthwhile to fetch to the comments feed in the first place.
Also, consider
Alternatively, you could decide to
trust that the feed publisher may have already done all this work and
has provided a reasonably accurate count in the form of the thr:count
attribute. It's your choice.
This to me is what its all about. I hear a lot of people saying that you
can't be sure
* James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]:
The slash:comments extension element can be used to provide a
global comment count that operates independently of the replies
link.
Supply per-link information as namespaced attributes on link
elements, if you must. I don’t like the idea,
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:
Very simple reasons: the attributes are easier to implement,
Speaking as an actual, rather than alleged, client implementer, I find
this assertion ridiculous and dishonest.
are allowed by RFC4287 and are being used in real deployments.
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2006-05-16 06:00]:
The slash:comments extension element can be used to provide a
global comment count that operates independently of the replies
link.
Supply per-link information as namespaced attributes on link
elements, if you
At 4:33 AM +0200 5/16/06, Robert Sayre wrote:
I thought the working group was fairly clear about the dubious value
and placement of these attributes,
For the benefit of Lisa, who is the sponsoring AD for this document,
please list links to those messages.
So you don't think they're
On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote:
At 4:33 AM +0200 5/16/06, Robert Sayre wrote:
I thought the working group was fairly clear about the dubious value
and placement of these attributes,
For the benefit of Lisa, who is the sponsoring AD for this document,
please list links to
Robert Sayre wrote:
[snip]
Looks like the IETF wants to publish a proposed standard explicitly
designed to break a very popular implementation, with no technical
reason. I think that speaks volumes about the IETF, its management,
and the quality of its individual contributors.
On 5/17/06, James M Snell [EMAIL PROTECTED] wrote:
What's broken?
Do you think the AD and this WG are dumb? Why are you setting up such
an obvious strawman?
Congratulations, your extension didn't break Atom. The point is that
your extension is broken. You're including attributes in that
* Robert Sayre [EMAIL PROTECTED] [2006-05-17 01:50]:
You have no technical reason that makes that location
compelling, and several WG members have questioned whether this
document adequately covers the area in question.
I have to disagree that there is no technical reason.
There is no way to
On 5/17/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
I have to disagree that there is no technical reason.
There is no way to sanely associate additional information with a
link element.
Sure there is, and it's the way James did it. Is the information
valuable? Does the spec cover cardinality
On 5/17/06, Lisa Dusseault [EMAIL PROTECTED] wrote:
- We're talking about visibility to implementations of the base
spec only, not implementations of the extension, naturally. Any new
information can be visible to implementations of that extension.
There's a misunderstanding here. Many
Hey all,
I'm happy to announce that the Feed Thread extension (draft -10) [1] has
entered Last Call. [2]
The thr:count and thr:when extension attributes are back in Draft -10
following the recent on-list discussion and post by Tim Bray affirming
that the atom:link element is indeed extensible.
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:
At this point, Feed Thread support has been deployed in Friendster,
Typepad, and MovableType.
I thought the working group was fairly clear about the dubious value
and placement of these attributes, and you yourself posted that no one
was
* Robert Sayre [EMAIL PROTECTED] [2006-05-16 04:45]:
[…]
+1
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Robert Sayre wrote:
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:
At this point, Feed Thread support has been deployed in Friendster,
Typepad, and MovableType.
I thought the working group was fairly clear about the dubious value
A few of the individuals on the WG had a problem with
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
Right, and you're breaking them because...? You haven't coherently
explained your
Robert Sayre wrote:
On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:
A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.
Right, and you're breaking them because...? You haven't
78 matches
Mail list logo
