Xapi-J: an architectural detail

[John Tigue]

Peter Murray-Rust wrote:

> <snip/>
> > To get an element's attributes:
> >      java.util.Enumeration someAttributes =
> anElement.getAttributes();
> ><snip/>
> I follow all this.  Can we also go one step further and say how we get
>
> the children of an Element.

To get an element's children:     java.util.Enumeration children =
anElement.getContents();

This method returns an Enumeration, each object of which implements
IContent. The below paragraphs explain IContent et al.

An XML document can be represented as a tree. In an XML document object
model there are things which are containers (e.g. a document is a
container and so is an element) and also things which are the content of
a container (e.g. a chunk of text is a content or even a element can be,
in the case of one element within another). To model these there are the
IContainer and IContent interfaces. The full source follows:

public interface IContainer
     {
     public Enumeration getContents();
     public void insertContent( IContent aContent, IContent
preceedingContent );
     public void appendContent( IContent aContent );
     public void removeContent( IContent aContent );
     }

public interface IContent
     {
     public void setParent( IContainer aContainer );
     public IContainer getParent();
     public String getData();
     }

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();
     }

The above states that an IElement can be a container and/or a content
and also has some other methods particular to being an element. So
although IElement does not directly have a method called getContents(),
it gets the method from its superinterface IContainer.

(Note that the Xapi-J method getType() follows the terminology of
XML-LANG and as such it implies completely different semantics than
com.ms.xml.Element.getType(). Xapi-J's getType() returns a String which
is the "Name" from production [33] of the spec. For example, in the
following:
<color>red</color>
The spec clearly says "The Name in the start-and end-tags gives the
element's type" so for the above example in Xapi-J getType() would
return a String with the value "color" not an int with the value 1 (i.e.
MS's ELEMENT constant). Microsoft has chosen an independent model in
which most objects in a document are com.ms.xml.Element and the
particular flavor of "Element" is determined through the getType()
method. In that model all of the following are "Element" types:
DOCUMENT, ELEMENT, PCDATA, PI, BETA, COMMENT, and CDATA.).

> <snip/>

> > (I have tested that Xapi-J can be implemented on top of msxml. I
> have
>
> Excellent!  What are your thoughts about NXP and Lark?
>

Lark maps very easily to Xapi-J. Xapi-J was designed by taking all the
best ideas from the existing processors so the mappings are
straight-forward. NXP is pretty much the standard when it comes to ESIS
output so it defines that part of Xapi-J making the mapping essentially
direct. The only new part is the stuff mentioned in the posting which
started this thread: how does a developer instantiate a processor
through the Xapi-J interfaces. After that it's the regular old NXP
stuff.

Note that since Xapi-J is pretty much just a bunch of interfaces, this
work can easily be fit into a full grove model. The objects in the grove
could implement their grove interfaces and if desirable also implement
the earlier Xapi-J interfaces. A full grove model is being work on by
others so making Xapi-J a full grove model would be a duplication of
effort. The main goal of Xapi-J is simply to make things easier for
developers using the current crop of processors.

<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/19970803/be6c700d/vcard.vcf