Friday, May 5, 2006, 12:20:25 AM, A. Pagaltzis wrote:
> * M. David Peterson <[EMAIL PROTECTED]> [2006-05-04 23:30]: >> Or is something like this simply inviting WAY TOO MANY little >> things to find justification to plug up the collective inbox of >> the community members? > I don’t know. So far during extension development discussions, > only the missing extensibility for links has stuck out as a real > sore point in RFC 4287. Other than that, the spec has stood up > very well with only a few minor errata reported here and there. > At least, that’s my impression; I don’t know what others think, > of course. > Frankly, I would hope there won’t be much interest – cause if > there is, what else would that mean than that we did a shoddy > job? :-) The RFC does a good job of saying what is and isn't a valid Atom document. What is out of scope of the RFC though, is the behaviour of processors that provide access to, store, or act as intermediaries for Atom streams, wrt what elements and extensions are retained. Not that all processors should behave the same, or that processors that retain the most information are necessarily "the best" (ones that retain less information are probably likely to offer more usable interfaces), just that extension authors need to be mindful of typical behaviours of processors, and vice versa. As the processing behaviour is not defined (not even in APP), application of the robustness principle is particularly relevant. I started on a document describing some checklists for the preservation of data required to meet several arbitrary conformance levels - intended more as considerations for extension authors, than for processor implementations. -- Dave
