Xapi-J: an architectural detail

[Peter Murray-Rust]

In message <33E75F5F.CC7EC38E at datachannel.com> john at datachannel.com (John Tigue) writes:

Firstly many thanks to John for driving this forward and for the positive replies
from several others. let's make sure that we get closure on this fairly shortly
as we don't want to fall back to where we were 4-5 months ago with a lot of
enthusiasm and no final outcome.

I know we are all doing this on a voluntary basis, but if we get it right this 
time we save a lot of problems later.  I have put my JUMBO development on hold
because I really want to get it on top of a decent architecture.  We need to
know precisely what an Element, Node, etc. are :-)

I get the impression from John and others that it is possible to create an
API which does not necessarily suport the property set today, but is capable
of doing it in the future without rewriting.  If so, then perhaps John and
others could suggest where they intend to freeze the current API at. If we don't
set some limits now, there is the danger that we try to be too ambitious.

As soon as an API is established, a benefit will be that we can start to think
about what other features of XML processing need to be covered in a generic 
manner.  I found that quite of lot of JUMBO implementation was generic 
(e.g. checking semantic validity, 'inheritance/default' implementation, etc.
which is not trivial and should be isolated as far as possible from applications.



> 
> Chris Lloyd wrote:
[...]
> > 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 with this - it should be possible to add these in at a later stage
(e.g. by subclassing in Java).  I have a lot of stuff in JUMBO that implements
treewalking (e.g. TEI Xptrs) and even tree-editing, and my Tree/Node classes 
can have up to 100 methods each. We want to avoid this at this stage :-)

> 
> 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.
> >

I tend to support this. It makes general management such as editing and display
easier, even if the Node objects are not of the same class.


	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

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