No subject

that the empty namespace becomes something rarely used than for
elements with children in the same namespace to become uncommon. The
use and expectation of a no-namespace element when namespaces are
becomming crucial and prevalent (and required to use the standards you
bring up) strikes me as both anachronistic and more likely to cause
semantic errors - the API user is using namespaces, why enable and
encourage him or her to even _think_ about a no-namespace element?
Shouldn't the api help the user steer clear of such vestigal
constructs?

I would also argue that simple hierarchal structures with a common
namespace or two are still and will most likely always be a
meat-and-potatoes, typical application of XML - complex
encapsulation/metadata/subset-definition/transformation standards will
remain and continue to be in use - they are indeed common and have a
lot of exposure. At the same time, inside most uses of these standards
are chunks and chunks of hierarchal structures with specific,
typically local structural and type (namespace/name) definitions. The
emergence of XML-based RPC/RMI formats such as SOAP will be another
generator of bunches of app-writer-specific, relatively
namespace-uniform XML fragments.

As the high-level standards solidify and gain acceptance, they are
much more likely to aquire their own, high-level, standard-specific
API implementations that spare us from the task of manually rooting
through document trees and writing custom code encapsulating the
semantics of one standard or another. JDOM is a low-level API and the
reason it will always be useful is that there will always be
application- and system-specific encodings of structures that are not
covered by a standard and require the implementor to roll his or her
own decoding and semantic interpretation code. In the brave new
namespace-infested world, are any rational users going to want to ever
use the empty namespace? I can't see any reason other than support of
legacy, XML 1.0/pre-namespace documents and document fragments.