XAPI-J refinement proposal

[John Tigue]

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

AND

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

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
Programmer
jtigue at datachannel.com
DataChannel (http://www.datachannel.com)
206-462-1999

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