XAPI-J refinement proposal

John Tigue jtigue at datachannel.com
Mon Jun 30 17:26:27 BST 1997

Currently in XAPI there is the interface IContent which has the methods
relevant to being a "node" in a parse tree/grove; accessors for parent
and children. Recent work has shown that there would be some benefit to
breaking IContent into IContent (child) and IContainer (parent). Also
there was feedback asking for addContent() to be extended to
appendContent() and insertContent(). This would look like:

package xml;
import java.util.Enumeration;
public interface IContainer
    public Enumeration getContents();
    public void insertContent( IContent aContent, IContent
preceedingContent );
    //  appendContent() puts aContent at the end of the list
    public void appendContent( IContent aContent );
    public void removeContent( IContent aContent );


package xml;
import java.util.Enumeration;
public interface IContent
    public void setParent( IContainer aContainer );
    public IContainer getParent();
    public String getData();

So a Document class (not currently part of XAPI-J) would implement
IContainer but not IContent. IElement would implement both. A Text or
Data class would implement only IContent. I don't see how this
interferes with any existing processors. I hope I have not missed

Another point is IContent.getData(). This is how, for example, PCData
would be retrieved. Grove terminology refers to non marked up text as
"data" so we have getData(). Except for this detail the method could
just as well have been called getText() (which was my first choice),
getString(), or some such.

Any comments?

John Tigue
jtigue at datachannel.com
DataChannel (http://www.datachannel.com)

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

More information about the Xml-dev mailing list