Xapi-J: an architectural detail

[John Tigue]

Chris Lloyd wrote:

> akirkpatrick wrote:
> >I really like the combination of IContent and IContainer.
> >The only question I have is how an element can query
> >its context in an efficient way? For example, how can
> >I find the previous element without referring to the parent
> >container. Presumably then the parent would have to
> >enumerate all its children to find the previous content
> >to the element in question. Obviously a particular
> >application can record the previous element in a variable
> >but then you get to more complex contexts, like "what
> >is the previous of my parent".
> >
> This is where the next step is needed. Tree Iterators can provide
> efficient
> and well abstracted mechanisms for walking the XML tree. Everyone is
> still
> stuck on the schema part of Xpia-j and that is fine. After that is
> done
> then it's time to add classes specifically for navigation.

> Keep the schema simple. Don't add members for the previous child,
> etc.. It
> is unnecessary and complex to maintain.

I agree. I think we should follow the Visitor design pattern. Quoting
from Gamma's _Design_Patterns_: "Intent: Represent an operation to be
performed on the elements of an object structure. Visitor lets you
define a new operation without changing the classes of the elements on
which it operates." Here the operation is tree interation.

>
>
> Over the past 2 years, we have been developing an object database
> system
> for SGML. We have gone through the same thought processes as are going
> on
> with xapi-j right now. I think there are a few design considerations
> to
> keep in mind if you want to use iterator classes with the xapi-j
> schema and
> I think eventually you will.
>
> The idea of inheriting from IContainer is a good one. Polymorphism is
> very
> useful when it comes time to write navigation classes. A base class
> for all
> objects in the tree is very important!! We'll call this INode.
>

public interface INode    {
    // What do we put in here?
    }

> <snip/>
> Again I stress that every XML object in the tree should inherit from a
>
> single base class even if the base class does not provide any common
> interfaces to it's concrete classes. In this way, any XML object can
> be
> passed via a base class reference(Whoops, I almost said pointer). It
> is
> trivia to implement a fast, safe-casting mechanism that uses
> polymorphism
> for casting.
>

So the interfaces in Xapi-J would extend INode like this?

public interface INode {...}

public interface IContainer extends INode{...}

public interface IElement extends IContainer {...}

This way an IElement is also an INode so passing via base interface can
be done for any object in the model. We're still dealing purely with
interfaces so vendors are still free to implement their own base
classes. This also could be mapped to CORBA, DCOM, and others.

> This way, we can later add navigation classes that leverage the
> polymorphic
> nature of the XML tree.
> <snip/>

--
John Tigue
Sr. Software Architect
DataChannel
http://www.datachannel.com
jtigue at datachannel.com
206-462-1999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vcard.vcf
Type: text/x-vcard
Size: 263 bytes
Desc: Card for John Tigue
Url : http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19970805/0d9759e5/vcard.vcf