Subject: issue roundup

From: Robert Sayre <[email-masked]>
Date: Fri, 04 Feb 2005 04:58:34 -0500

I am getting sick of arguing with you people. :)

Here is my opinion on every open issue, FWIW. I doubt any of my opinions 
will be controversial. You might disagree with one or two of them, but 
I'm guessing I predicted the WGs feelings pretty well. It's probably a 
waste of your time to argue about your pet Pace for another couple 
weeks. Listen to Paul.

-------------------------------------------------------------------

HeadInEntry - Fine keep it. I think it's a stupid way to do one-item 
feeds, but it doesn't hurt anything, and I'm not going to explore your 
strange religion any more than I already have.

PaceExtensionConstruct - a.k.a. don't put stuff in stupid places. The 
text there is close enough to give to the editors.

PaceFormatSecurity - Could live with this if I had to, but mine is way 
better.
PaceSecuritySection - Yes, let's use this one.

PaceIconAndImage, PaceEnclosuresAndPix - Use @rel="icon", not a new 
element (we never settled any meaning for atom:link, so html convention 
wins). Use @rel="enclosure". Use an image element if you want sizes, 
otherwise use @rel="image" and 1:1. Don't limit it to atom:head, haven't 
you ever read a livejournal? We already have @length, please read the 
draft before writing a Pace.

PaceMultipleImages - No. No. No.

PaceLinkRelVia - people already use it, it's cool, and straightforward. 
Yes please.

PaceCollection - overloaded term. how about "trough"?

PaceMustBeWellFormed - Horrible. -1. I've explained why many times, yet 
people persist in applying the term "well-formed" whenever someone does 
something stupid with XML.

PaceOrderSpecAlphabetically - Sure.

PaceRemoveVersionAttr - +1, people just change formats and leave the 
version number "for compatibility".

PaceRemoveInfoAndHost - World Record Consensus. +1.

PaceTextRules - purports to tighten up rules, but uses only MAY and 
SHOULD. I would say "undefined" instead of MAY about xml:space. I wish 
we could say "clients will do this" instead of SHOULD. -0

PaceXhtmlNamespaceDiv - -0

PaceAggregationInSeparateSpec- How about PaceAggregationInSeparateWG?

PaceCommentFeeds - link @rel="comments". Sure, ok.

PaceFeedState, PaceNoFeedState - a good effort by mnot to set up a 
dichotomy and therefore appear to compromise when the less radical one 
is chosen. I want to reject both of them.

Archiving - Atom is perfectly good for archiving blogs. Most objections 
venture into archiving the state of a web server. Some things you might 
need if you were going to do that: A way to represent negotiated 
resources, a way to represent source and derived resources, a way to 
represent resources which act on others... all the stuff you would need 
to serialize the state of Movable Type. I just use mysqldump.

PaceAggregationDocument - Kinda scary, but also pointless.
PaceFeedRecursive - Scarier, but more useful.
PaceEntriesElement - Really rather useful, but the scariest of all.

These are so scary, Tim called them SGML/Lisp/ArchitectureAstronautics 
all at once. Note to Tim: It's faster if you just say "C++". Obviously, 
these aren't going to happen. OK.

-------------------------------------------------------------------

I think that about covers it.

Robert Sayre