[
Lists Home |
Date Index |
Thread Index
]
- From: jtigue@datachannel.com (John Tigue)
- To: xml-dev@ic.ac.uk
- Date: Mon, 30 Jun 1997 08:27:42 -0700
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@datachannel.com
DataChannel (http://www.datachannel.com)
206-462-1999
begin: vcard
fn: John Tigue
n: Tigue;John
org: Datachannel
adr: 10020 Main St.;;#205;Bellevue;WA;98004;USA
email;internet: jtigue@datachannel.com
tel;work: 462-1999
tel;home: 498-4708
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
end: vcard
|