XObjects

[Tyler Baker]

Bill la Forge wrote:

> From: Tyler Baker <tyler at infinet.com>
> >(1) There is a root element handler that is passed to the parser which
> handles
> >all of the events generated by parsing the root element.  If a new child
> element
> >of the root element is encountered, the root element is responsible for
> >instantiating an element handler for the given element name.  If no element
> >handler can be instantiated then null is returned.
> >
> >(2) All of the generic events of SAX you could consider are delegated down
> to
> >the currently selected parent element which is receiving character,
> element, and
> >pi events among others.  This is done natively in my parser and has nothing
> to
> >do with SAX per se, but this sort of framework can be easily built on top
> of SAX
> >in a few hours I would think.  I personally have had a lot of success using
> this
> >method (I will admit my opinion is biased by my own personal adulation) and
> find
> >it to be just about as straightforward as using Java Object Serialization
> as a
> >framework for reading and writing object state.
> >
> >(3) No registry, bindings, or any other muckety muck is necessary.  All you
> need
> >is an instantiated implementation for a root element which knows how to
> >instantiate children elements who know how to instantiate children elements
> and
> >so on and so forth.  It is equivalent to calling readObject() in Java
> Object
> >Serialization where you need to know the root object type to case to, but
> you
> >don't have to worry about the types of any of the child objects as the root
> >object knows what types they need to be cast to.
>
> As a component programmer (distinct from an oo programmer), I attempt to
> avoid
> embeding in a component class any knowledge of other component classes.
> (A component may know about interfaces and objects, but not other
> components.)
> The last thing I want is to have components created by other components
> using
> the new operator.

Well if you are building any data structure, the children must be some type
which the parent nodes unde, even a very abstract type.  In the element handling
code, whether you choose to reference the element handlers returned as
interfaces or objects is at the application programmer's discretion.  Unless you
are going to have a completely abstract tree of very primitive data, I feel you
need to do this.  The approach of subclassing org.w3c.dom.Element is similiar to
the approach I am talking about except the approach I have says nothing about
how the application chooses to build the abstract data structure that may fully
or partially represent the XML data.  In addition, unknown element types can be
conditionally ignored (as well as their corresponding children) at will.

> Coins supports this programming style--all you need is a binding for the
> smart root.
> My own programming style depends on either factories or (preferably)
> binderies.

This approach I feel is great for systems like GUI's which have a pretty strict
contract on their layout (i.e. in some manner component a is located it point
x,y in component b's container space) which can easily be constructed with a
binding type system.

> Shouldn't XObject be able to accomodate diverse styles as well?
> OK, it means moving closer to the SAX DocumentHandler interface than what I
> had proposed. We need a START-ELEMENT to accomodate this.

It really does help, especially for applications which may want to create
temporary list objects to store an unknown number of child elements.  Sometimes
you don't want everything represented internally as a list, but you need the
list for convenience in storing these objects during the parsing process.  When
endElement() is called, the list is discarded and the contents are dealt with as
such.

> But then we've constrained the implementation. Tough choice. Perhaps a DOM-
> specific set of arguments on that START-ELEMENT would be a good compromise:
>
>         public void startElement(
>                     java.lang.String name,
>                     org.w3c.dom.NamedNodeMap,
>                     org.xml.sax.Location)
>             throws SAXException;

This would work fine if you are first building the DOM and then reparsing it
before presenting the events to the application.  I am just saying why not
eliminate the overhead of building the DOM tree in the first place and send it
straight to the app.

> This again allow for greater integration with the DOM without either
> precluding or excluding the use of SAX.

Is this a goal?  Why should we be working with the DOM for DOM's sake.  I just
don't see the reason why the DOM is necessary here and I consider it to be an
intermediary form of bloar.

Regards,

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)