Sylvain Hellegouarch wrote: > > Hi James, >> For me it's a matter of the fact that the spec has gone through 6 >> revisions and two design overhauls since it was first pitched. It's >> been out there for quite a while. At some point, the design discussions >> need to end and it needs to stablize so that folks can do something real >> with it. If, during that process, some folks get annoyed, so be it, >> that's the nature of the game. > Well I find you a bit aggressive here I haven't said I was annoyed nor > anybody else. I'm sorry for not being there during the first months > you've put that draft in shape. There is no place I have seen where you > said in the first place the discussions were over until now by the way. >
Not a problem :-) I had announced an informal "last-call" back around the December 2005 timeframe. But that was more or less designed to get folks to actually read the spec than it was to lock things down. The discussions are definitely not over but I want to avoid making generally cosmetic changes because there are always going to be some folks who aren't going to be happy. >> No spec is perfect, nor should we waste >> our time trying to make them so. Is the spec good enough? I think so. >> > You do but recognise at least that what was merely a question from my > part showed that a few people hanging around here agreed on the > misleading name and a good alternative was quickly found. You have the > right to dismiss of course. I also agree that the name change would be good and I seriously considered making the change. If I hear from enough implementors that say changing it would not be a problem, I'd likely go ahead and do so. (e.g. when I say "final" I usually mean "more than likely final but I'm always open to be convinced otherwise" ;-) ..) >> Are there any functional bugs? I don't think so. Can the spec text be >> improved? Definitely, and I'll likely do so one more time between now >> and when it's actually submitted for consideration as a standards track >> RFC. >> > Well I wonder how since you define what's important and what's not. > Please don't misinterpret, I'm not disregarding any point of view on this. I've seriously considered every bit of feedback offered and greatly appreciate it.. and, like I said above, it's always possible to convince me to make a change if there's enough support for it. So, with that, let me go ahead and open it up to a vote with the caveat that votes from folks with concrete plans to implement the spec will carry more weight so I'd appreciate a heads up. 1. Do I change <in-reply-to id="..." /> to <in-reply-to ref="..." /> ? and.. to address David's concerns about extending atom:link... 2. Do I change thr:count and thr:when to extension elements instead of attributes on atom:link? None of the implementors I'm aware of are currently making use of multiple replies link relations on an entry so changing #2 likely wouldn't cause too many headaches. My apologies if I came across a little too heavy handed on this. That was most definitely *not* the intention. - James
