Venkat Reddy wrote:
Alek,
Like i said in the earlier thread on the same subject, there are
couple of issues if we move the child API from OMElement to a seperate
interface. The excerpt from my old mail:
"The client API currently uses OMElement.addChild() to build the
message. Even if
we try to use setParent() instead of addChild() here, the user has to
typecast the OMElement into OMElementImpl and pass it to setParent,
which is not elegant."
Venkat,
why not have interface OMElement extends XmlContainer, XmlContained
and interface OMDocument extends XmlContainer
where interface XmlContainer has all child meanagement methods (so they
are shared)
and XmlContained is used to mark that item has parent, like
public interface XmlContained{
public XmlContainer getParent();
public void setParent(XmlContainer el);
}
that should solve all problems?
Do have any ideas to resolve this? Until we get new ideas, here is my
+1 for OMDocument extends OMElement.
note also Infoset Document item has no parent! and that is significant!
alek
--
The best way to predict the future is to invent it - Alan Kay
