What is the reasoning why a well-formed XML text cannot have multiple top level elements?

[Clark C. Evans]

Thanks Tim!  This is *really* good, I think I just 
changed my perspective on things.  I had been wondering
if I had missed something... 

On Sun, 19 Dec 1999, Tim Bray wrote:
> Both logfiles and continuous broadcasts work just fine, simply send
> a series of small XML documents rather than try to pretend the whole
> logfile is one parsable object.

Yes, using "^L" as the document seperator. 

> Which is arguably better design anyhow; to start with, among other 
> things you can validate each record; in principle you can't validate 
> a doc until you've read it all.

Well, if you consider "is-valid()" to be a property of the
XML source as it is encountered, then is-valid() is itself
not a value, but a sequence of values.  The last value having
particular relevance in the "document" domain.

> I've always thought the single-root-element idea was a good one for
> networked apps simply because it allows you to know unambiguously when
> you're done receiving useful data, and don't have to rely the programmer
> at the other end closing the socket, and the connection teardown time,
> and so on.

Yes.  Ok.  This one clicks.  Assume a broadcast, let's say from 
a programmable controller watching 4 gauges and reporting their
differentials.  The broadcast has a definite beginning.  I always
thought of it as "infinite" beacuse in practice, the controller
can be left on for years...  However, there may be cases where the
controller needs to be shut down for maintanence... thus, switching
the power switch to "OFF", would first send the end tag, and then
power down.  Ok.  I can grok this one.  Thanks tons!

Perhaps the log file might be similar?  Let's say I startup
a-daemon-with-xml-logging.  It would start by creating a new
log file by picking the date/time of the run, and then 
write out the <log> element.  As events occur, they are 
appended as <event/> elements to the file.  If the daemon 
is shutdown gracefully (99.9% of the time), then it can end 
the log file with a </log> tag.  Nice.  So, there are only 
two cases where a log file would not have an end-tag: 
(a) if the file is read while the deamon is running, or 
(b) if the daemon crashes.   

In both of these cases above, SAX can be used to report
on the stream as it arrives anyway...  This leads me to 
a question:  How do SAX implemetations (like XT) treat 
files that are opened for writing by another process.  
Is it possible for them to have behavior like "tail -f" ?

> But the real reason XML was done that way was becasuse it was one of
> the things inherited from SGML that nobody ever asked to have changed.
> Really, I don't recall a single word on that subject at the time. -Tim

This is cool.   Thank you for humoring my question!

;) Clark


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)