Xapi-J: an architectural detail

[Chris Lloyd]

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.

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.

It then becomes useful to break the type of nodes into 2 classes.
IContainer and IProperty. An IProperty is always a leaf node of the tree
and an IContainer is not. After that you add your concrete classes such as
IElement.

John Tigue wrote:

>These interfaces only express the methods for navigating a tree. A
>particular class of objects would need to have some more methods to be
>interesting. For example, the interface for an element is IElement. The
>full source follows:


>public interface IElement extends IContent, IContainer
>    {
>     public String getType();
>     public void setType( String aType );
>     public void addAttribute( String name, String value );
>     public void removeAttribute( String name );
>     public IAttribute getAttribute( String attributeName );
>     public java.util.Enumeration getAttributes();
>     }

In the above example the returned interface IAttribute would inherit from
IProperty because it is a leaf node.

A Tree Iterator would already now the structure of an element when it walks
over it an would know how to retrieve the attributes. When it walks on to
an attribute, it knows it's a leaf node because it inherits from IProperty.

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.

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

Chris Lloyd
POET Software








>Any thoughts?
>Alfie.
>
>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)
>
>

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)