#30 Allow nested parsing (in the OO way)


One of the basic tenets of OO programming is that an
object encapsulates data and all the methods for
working with that data.

When outputting XML from an OO language, this is easy
to stick to - (to use java terminology:) each Class has
a toXML() method, or similar, and outputs XML for any
instances of itself, which can easily be nested in a
bigger XML document. Usually, a toXML() method recurses
to any/all non-trivial Object variables amongst the
Class's data.

However, when attempting to load data via SAX, it seems
much harder to keep to OO practice - it is not simple
to load an XML document by having one object
parse/respond to the tags it recognises, and delegate
the ones it doesn't recognise to other classes.

I can't see how to do this without resorting to hacks
that are non-OO: you end up having to tightly-couple
classes that have no reason to be tightly coupled.
Alternatively, you create a "loader" class that parses
XML and sends the different nested chunks to different
classes. But this is again non-OO, because now you have
shared the data of those classes with this loader
class, creating an artifiicial dependency (e.g., you
cannot change the XML method source in ANY of the
classes without also changing the source of the loader

Perhaps I'm being stupid and there is a simple, OO way
of using SAX to load XML into an OO system. If so, then
I'm RFE'ing that it should be explained in the docs. If
not, I'm suggesting one is necessary. The most obvious
advantage I can see is to greatly simplify any
XML-based serialization performed (for whatever
reasons) in OO applications, but it also has advantages
wherever large, complex data structures that represent
data from more than one object (which may have nothing
to do with object-serialization), are being parsed from
XML by an OO app.


  • David Brownell
    David Brownell

    • status: open --> closed
  • David Brownell
    David Brownell

    Logged In: YES

    There's not "just one" OO way, and there are several
    perfectly good layers written over SAX that solve this
    class of problem to the satisfaction of various groups
    of developers.

    SAX is just intended to be an efficient parsing API,
    and can't be expected to solve all problems. And
    for that matter, XML itself isn't an "object oriented"
    text syntax ... you can adopt OO policies with it,
    but that doesn't change XML.

    Rejecting this since the problem is for layers above SAX.

  • David Brownell
    David Brownell

    • status: closed --> closed-rejected