Hmm, I've been a little distracted, but I thought PaceExtensionConstruct did get a reasonable amount of support. +1 from me anyway.
On Tue, 15 Feb 2005 11:12:48 -0800, Tim Bray <[EMAIL PROTECTED]> wrote: > > Methodology: Paul & I went through *all* the WG emails that directly > commented on the currently open issues (see > http://www.intertwingly.net/wiki/pie/AtomPubIssuesList); in most cases > the calls were pretty clear. As always, we may have mis-read the > group, feel free to say so if you think so. > > The intent is that this email serve as guidance for the editors in > preparing the format draft that we send out for IETF last call. We do > not expect further material discussion of format-related Paces, it's > now over to the whole IETF. On the other hand, discussion of editorial > changes is always fair game, please keep reporting what you find to the > list, and we wouldn't be surprised if the editors turned up some corner > cases too. > > PaceAggregationDocument & PaceAggregationDocument2 > One -1, nobody unambiguously in favor. > DISPOSITION: Close them. > > PaceAggregationInSeparateSpec > Only a couple of voices in favor, some support conditional on profiles. > DISPOSITION: Close it, but given that the other aggregation-related > Paces seem to be failing, it seems like a separate spec is the only > place that this kind of work gets done. > > PaceArchiveDocument > A howling mob of sharp pointy -1's. > DISPOSITION: Close it. > > PaceClarifyDateUpdated > A couple of -1's, one fuzzy +1. > DISPOSITION: Close it. > > PaceCollection > One pro, one contra, not much discussion. > DISPOSITION: Not enough support, close it. > > PaceCommentFeeds > Two contra, one pro, some suggestion that we really need > link/@rel="comment". > DISPOSITION: Not enough support, close it. > > PaceDatesXSD > Everyone seems to like it, enough people want the regex that it's > accepted too. > DISPOSITION: Accepted, Sayre suggested good wording calling in all the > specs that are covered. > > PaceEntriesElement > Drowning in -1's. > DISPOSITION: Close it. > > PaceEntryOrder > One -1, but overwhelming support otherwise. > DISPOSITION: Accepted. > > PaceExtensionConstruct > One -1, 1.5 +1's. > DISPOSITION: Not enough support, close it. > > PaceFeedRecursive > Lots of -1's. > DISPOSITION: Close it. > > PaceFeedState > Lots of -1's. > DISPOSITION: Close it. > > PaceNoFeedState > A few +1's, nothing negative. > DISPOSITION: Accepted. > > PaceFormatSecurity > Evenly split +1's and -1's. > DISPOSITION: No consensus and we have PaceSecuritySection, close it. > > PaceHeadless > Lots of talk, more -1's than +1's. > DISPOSITION: No consensus, close it. > > PaceIconAndImage > One -1, but broad support otherwise. > DISPOSITION: Accepted. > > PaceLangSpecific > Not a lot of discussion, but pretty positive. > DISPOSITION: Borderline, but accepted. > > PaceLinkEnclosure > A little bit of support, but with reservations. > DISPOSITION: A messy Pace and not enough support, close it. > > PaceLinkRelVia > Moderate support, no objections. > DISPOSITION: Borderline, but accepted. > > PaceMultipleImages > Lots of -1's. > DISPOSITION: Close it. > > PaceMustBeWellFormed > Very little discussion, no unambiguous support. > DISPOSITION: Our longest-lived Pace is finally closed. > > PaceOrderSpecAlphabetically > A bit of support, not much talk. > DISPOSITION: This is editorial, let the editors run with it. > > PaceProfile > Changed along the way, quite a few +1's but even more -1's. A certain > amount of "+1 on concept, -1 on syntax" which doesn't help. > DISPOSITION: No consensus, close it. > > PaceProfileAttribute > No significant support. > DISPOSITION: Close it > > PaceRemoveInfoAndHost > Not much discussion, but no opposition. > DISPOSITION: Borderline, but accepted. > > PaceRemoveVersionAttribute > Quite a bit of support, quite a bit of grumbling but no loud -1's. > DISPOSITION: Borderline, but accepted. > > PaceRepeatIdInDocument > Lots of discussion, more -1's than +1's. > DISPOSITION: No consensus, close it. But now we have a problem, in > that this removed ambiguity in one direction, just closing it leaves > the ambiguity. So the only logical conclusion is that the WG is > directing the editors to put language in that explicitly forbids > entries with duplicate <atom:id> in an <atom:feed>. > > PaceSecuritySection > More support than opposition, but some feeling that the IETF is going > to make us do something like this anyhow. > DISPOSITION: Borderline, but accepted. > > PaceTextRules > Only one (positive) comment. > DISPOSITION: Not enough support, close it. > > PaceXhtmlNamespaceDiv > This is tough. There are some people who are really against this and > who aren't moving. On the other hand, there are way more who are in > favor. Reviewing the discussion, the contras are saying that this is > sloppy and unnecessary and if it solves a problem, that problem really > shouldn't be there, but they don't seem to be saying it's actively > harmful. But the people in favor are arguing that this will reduce > errors and improve interop. Also, the Pace was changed in midstream. > Also, Paul thinks we will get feedback on this from out there in the > IETF. > DISPOSITION: Borderline, but accepted. > > =================================== > > None-Pace discussion items: > > Remove Protocol stuff? See > http://www.imc.org/atom-syntax/mail-archive/msg13431.html > Several +1's, some grumbling. > DISPOSITION: Let's do it; Paul thinks we'll get IETF feedback on this. > > s/tagline/subtitle/ had unanimous support, says Parks: > http://www.imc.org/atom-syntax/mail-archive/msg13452.html, and no > push-back > DISPOSITION: Do it. > > -- http://dannyayers.com
