[I surely rehash things heard on this list before...  --vg]

> While that time has not come, it is a provocative thought experiment to
> speculate on the shape and characteristics of its successor.
> o  A simpler XML?
> o  A smarter XML?
> o  Binary XML
> All known and there have been attempts.
>
> o  Objects
>
> The third is what some were after before the web.  Why not send compiled
> objects?  (I know some of these reasons but from time to time, it is
> useful to start from a fresh perspective.)

There is comfort in receiving only data, without anything executable ---
for security reasons, if not anything else (data can be inspected for
absence of harm, code has to be trusted; even sandboxing does not help if
the code is expected to produce side effects that are not easy to roll
back).  However, people in universities do work on solving the security
side of the problem --- "proof-carrying code" (PCC) is one relevant
keyword.

Security aside, there is the problem of semantics --- how can I be sure
that your compiled objects correctly implement my expectations about data
handling?  In principle, PCC can help here too (you'll just send along
with your objects a proof for my formal requirement about semantics, and
I'll check it), but this isn't likely to happen soon in practice, since
the problem is hard, and the current efforts do tend to concentrate on
the security issues (those are funded better, too!).

Most of all (for me), objects wouldn't be "simpler XML" for sure!  Back to
the list of alternatives, I'd vote for "simpler XML", defined as an
abstract (but precise) data model, which is primary, with the textual
presentation being just a serialization mechanism.  This would mean that
(next-XML)-based technologies (authoring tools do not count!) are required
not to depend on the textual details, but only on the data model.

VG