Application architecture components affect how
systems interact with each other and with external systems.
SAX doesn't constrain these components,
which include data interchange formats and messaging
paradigms, because it lets you use XML in any way you
(or your systems partners) need.
In contrast, settling early on higher-level XML APIs
will constrain application architectures in many ways,
often affecting XML structures used for interoperability.
For example, many SOAP toolkits expect an RPC paradigm
using W3C-style XML schemas, and many data-binding approaches
demand a particular schema system and API toolset.
The hope is that if you accept those system constraints,
you win more than they cost. When that doesn't work,
perhaps because the constraints don't suit your application,
you'll appreciate the flexibility of SAX.
The design level affects application internals rather
than the broader interfaces, which relate to architecture.
Design constraints affect runtime and implementation costs.
If you're adding XML support to an existing system,
design-level concerns may dominate your planning.
SAX lets you use your current optimized data structures or
define new ones.
Since such design issues will often dominate performance
measurements (given reasonable architectures),
preserving flexibility can be very important.
With SAX, you don't need to use generic
(and largely untyped) data structures.
You will normally store data directly into specialized data
structures as SAX delivers it from its XML representation.
This facilitates important architecture-level optimizations.
Being able to use custom data structures means you can
leverage the strong data-typing facilities in Java and
detect many kinds of bugs early, while recovery is possible and cheap. Custom data decisions are the ideal way to work with large documents, for other cases where scale
is a major concern, and anywhere that data structure decisions
need to be driven by application issues rather than
"one size fits all" generic tools.