Walter Underwood wrote:
> Except that an endless document can't be legal XML, because XML
> requires the root element to balance. An endless document never closes
> it. So, the endless document cannot be legal Atom. Worse, there
> is no chance for error recovery. One error, and the rest of the
> stream might not be parsable.
It's not quite as bad as you suggest. In fact, in an Atom streaming
application, clients should be expecting that that </feed> element could
arrive at any moment. This is how the server would announce that it is
terminating the stream. Servers might want to do this to shed load,
shut-down for maintenance, etc. So, it isn't right to say that the document
"never closes." In fact, I think the reason for the closure will typically
be that there is a network error or that the client (or some infrastructure
component serving the client) voluntarily stops reading the document. In
these cases, it is reasonable to suggest that the client should have
procedures to recover a partial document.
Also, it should be noted that error recovery can be simplified
greatly if one is working with chunked content flowing over continuous HTTP
sessions. If one makes a simple rule that HTTP Chunk data will only be
inserted into the feed *in between* atom:entry elements, then you are
provided with the "framing" data needed to recover from any parse errors
with individual entries. This simple rule could be adopted by those who are
streaming over raw TCP/IP sockets as well. Perhaps what we need is "Atom
over Continuous HTTP" to be defined in addition to the "Atom over XMPP"
specification.
I'm afraid that the point that is being argued is a fairly fine
technical detail that really shouldn't be allowed to get in the way of
implementing practical and useful systems. We have a great deal of industry
experience with this sort of XML streaming model if only because the Jabber
folk and the fact that the IETF has approved XMPP as an RFC. These "endless"
documents are not actually endless. We simply need to import some existing
knowledge about how to do partial document error recovery and we're where we
need to be.
bob wyman
