> >   " [a]Living in the States must be a great y'all [b]" [c], [d]said ..."
> >Those intrusive spaces are what most browsers will do with the record
> >ends.
> [NOTE: I've added [a] and [b] above after the intrusive spaces,

You missed two :-)

> instead of using "^^" indicators, for those like me whose idiotic
> bloatware mail programs prevent them from using monospaced fonts
> unless they put the whole mail into HTML.]

Eww. Sorry, I had no idea such a thing existed (that won't _allow_
fixed-width characters).

> Leaving aside browsers, isn't it the case that with a conformant XML
> processor, the whitespace will simply be passed through to the application?
> (By XML clause 2.10).  Thus, spaces at [a] and [b] will and must "intrude"
> and it's up to the composition program to deal with them.  However, with
> a compliant SGML parser -- correct me if I am wrong, here, Peter -- the
> spaces at [a] and [b] will be ignored, because they are all in element
> content, not mixed content. (By the opaque clause 7.6.1).

If they were in element content, yes, regular SGML ignores them, and
if they were in mixed content then they are treated as data.  But XML,
although it specifies that all white-space is data, also says that a
parser can (?should ?must) report to the application on whether those
spaces were founf in mixed content or element content.  The problem
with DTD-less operation is that you may not be able to deduce until
the bottom of the document whether or not a space at location X
earlier was in mixed or element content. Hence a DTD is important.

> But does it really resolve to the same stream?  (Again, the mailers may be
> messing up the whitespace in the examples.)

No, you're right. I was assuming the application had enough wit to
append a space to the prefixed text, which is not the same thing as
having the parser resolve the data to the same stream.

> Hmmm, guess we need the DTD after all, even in the relational world.)

Absolutely. That's what it's for.

> I was concerned to know how this "join" approach handled mixed content.
> The answer: it doesn't.

If the only meaning assigned to "join" is simply that of the ownership
of an attribute I'd say the question is not relevant here.

> (3) Is it really necessary, as the examples given suggest,
> that mixed content must be eliminated from XML documents in order to treat
> them as "objects" in relational databases?

Not if you use a parser which can identify them for you.