Friday, May 20, 2005, 8:02:49 PM, Paul Hoffman wrote:
> Does the WG want to be able to open up new topics, or re-open old > topics with a twist? If so, do we all agree to the delay in > publication that comes with that? What would the minimum delay be out of interest? 4 weeks? 6 weeks? > Also, how long should this opening > and re-opening last? Are there any limits on which parts of the spec > we are willing to change? I'd be more comfortable with another round. A major motivation of Atom was to avoid the ambiguities of RSS, so we'd better not have any ourselves. I have some concerns about these issues still: a) PaceAllowDuplicateIDs was made after Last Call and is a pretty fundamental change to the Atom model. Its effect, that entries can have multiple instances, is an invention that none of the RSS specs cover. I think that we're rushing this without having time to think what effects it might have. (I'm basically in favour of it, but I think that it needs a bit more thought). I think that the debate on atom:version/atom:modified was curtailed prematurely (within 3 days) and should be re-opened. b) Hopefully we wouldn't try to add new features to Atom if we did another round, but allowing multiple authors seems to have some merit to it. The current text inhibits multiple authors being described even by extensions. Hopefully we can get a minimal base that would allow multiple authors to be described, deferring as much as we can to extensions. Robert Sayer's suggestion looked promising, but inheritance issues would need to be considered. And a few issues that are probably editorial: c) The language introduced by PaceAllowDuplicateIDs implies important properties of entries that ought to be made explicit. Throwing the word "revision/version/whatever" into the spec somewhere would make things clearer, and would be a useful vocabulary term for people who plan to write further specifications for extensions etc. (In the same way that Jeff Mogul's paper, "Clarifying the Fundamentals of HTTP" [1] defines the term "instance" for HTTP in a way that gave a basis for RFC3229 - "Delta encoding in HTTP" [2] d) The MIME specs don't give us very good terminology to describe what is allowed in places that allow "MIME types". I think we should explicitly say that we mean a MIME type to be composed of a main type and subtype with no parameters. It wouldn't do any harm. e) Inheritance of things like atom:copyright and atom:author seems rather subtle. They appear to work in slightly different ways, and I'm not sure that the spec is clear enough on exactly how this inheritance is supposed to work. As Dan Brickley said recently, "Atom's job [...] is to be clear about what the document means." I was planning to methodically enumerate some possible effects of inheritance, and to check whether the spec is ambiguous about any of these (it might all be fine). Eg: should an impeccably behaved Atom implementation treat these two the same (eg should a server record the two differently in its database): <feed> <atom:entry> <atom:author><atom:name>David Powell</atom:name></atom:author> [...] vs: <feed> <atom:author><atom:name>David Powell</atom:name></atom:author> <atom:entry> <atom:author><atom:name>David Powell</atom:name></atom:author> [...] Apart from that, I think things are pretty solid. [1] http://research.compaq.com/wrl/people/mogul/www2002/mogulwww2002preprint.pdf [2] http://www.ietf.org/rfc/rfc3229.txt -- Dave
