Re: [xml-dev] Nested Documents (was: XML 2.0)
> I don't understand what you mean by "more tightly linked"...
In a single-rooted document, <a>...</a>, when I see that final closing bracket I can be pretty sure that I've got everything. (Yes, trailing comments and PI's I handwave aside.) If the input stream ends before that closing bracket, then I know something went wrong. My XML consuming application can pretty much treat the input as a stream of bytes and not care where how or why something went wrong; at least at the first level. See the bracket, things ok; don't see the bracket, something broke.
Now, let's imagine a multi-rooted document like <a>...</a><b>...</b>. How do I know when I hit the end? Suppose the network drops after the </a>? If you're using something like TCP socket API, you have no idea how many bytes were in-flight when the connection dropped. (TCP is realiable only when its working; it's failures modes are pretty pitiful.) Suppose I'm reading a log file and there's no free space on the disk but I do see the closing </b>. Is that coincidence -- did the producer just get lucky and take the last bits of the disk, or am I missing <c>...</c> and friends?
There's no way to know, in a generic way, without doing very specific things depending on when where why and how the XML is transported. Right now, you don't have to. Yes, that's a simplification, 80/20, whatever you want to call it. I'd call it a trade-off and say the current design is the right one. :)
It has issues in the real world, too. Suppose you're writing a book and someone inserts a pagebreak between <a> and <b> in a multi-root document. Are they gonna get confused or misled if they're not explicitly told to turn the page?
/r$
--
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/