xml-dev - Re: XObjects (was TLAa was SOX)

[Tyler Baker <tyler@infinet.com>]

Graham Moore wrote:

> I like XObjects. XObjects IS what we are doing. Its like CLOS - common lisp
> object system.
>
> Does that mean we could have XOS - XML Object System ! SOX backwards makes
> it all a little confusing I fear. :)

This sounds like a good name but it is hard to pronounce.  Maybe something like
XBind since this in essence is a binding framework for mapping XML Elements to
programming language objects or structures.

> anyway interfaces.........
>
> >        public interface Bindings
> >        {
> >                        public org.w3c.dom.Document
> >                convert(org.xml.sax.InputSource inputSource)
> >                       throws SAXException;
> >        }
>
> i think the above is at the right level. Is this part of a domBuilder
> interface?

The DOM is a general purpose tree for storing the parsed contents of an XML
stream.  I really don't like this subclassing idea very much though as the DOM
I believe is not suitable for this type of framework since you are no just
dealing with Element nodes but you are dealing with all kinds of nodes.  I
prefer a framework which says nothing about how the object tree is created or
even if there is an object tree.  The application should be responsible for
doing this...

The proprietary Element interface of the parser I have has a method witht he
signature:

Element forElementName(String name, int index);

What this says is that for a given element name, that particular element is
responsible for returning an object implementation which satisfies the element
type.  This allows the application to easily build its own in-memory tree (this
is what I used for the DOM implementation) in any way it sees fit, or else not
build an in-memory tree at all.

Generally in Object-Oriented Programming you are dealing with graphs (or in
this case just a tree) of objects.  You can make the assumption that each
element has some idea of what type the child elements are in most cases, and in
the cases where the type is unknown or opaque, you can return a general purpose
Element implementation.

I have found this data-driven approach to be a lot easier to deal with than
just SAX although this is a good candidate for something that can be layered on
top of SAX (right now I do this natively in the parser).  SAX is a simple lower
level tokenizing interface for XML Parsers and does the job well, but for a lot
of applications, dealing with SAX events is not unlike going back to the good
old days of C and building all your data structures out of a few functions when
parsing a data stream.

So if I have a rectangle object that has 4 possible children, x, y, width, and
height the code for implementing the forElementName method would be something
like:

public Element forElementName(String name, int index) {
  if (name == "x") {
    this.x = new X();
    return x;
  }
  else if (name == "y") {
    this.y = new Y();
    return y;
  }
  else if (name == "width") {
    this.width = new Width();
    return width;
  }
  else if (name == "height") {
    this.height = new Height();
    return height;
  }
  return null;
}

where objects X, Y, Width, and Height implement the element interface as well.
Of course it would make much more sense to treat all of these as attributes
here, but I am just using this as an example.

For the last 6 months I have been using this approach successfully in an
application which may have no knowledge whatsoever of some of the child content
in the element tree, only that it has an idea of how to dynamically instantiate
the element handler for that particular content.

I think it would be a shame if this XOS API (or whatever it is named) favored
some registry based interface or mapping interface cause everyone has already
done these sort of things already for all kinds of applications and in the end
you usually find yourself in a configuration nightmare maintaining all of these
mappings.  One example is CORBA.  An example where the dynamic approach to
proxies works beautifully is in a distributed object architecture for Java
called Voyager from ObjectSpace.

My comments,

Tyler


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