axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [Axis2] Need for children API for OMDocument
Date Wed, 01 Jun 2005 07:06:22 GMT
jayachandra wrote:

>Can someone respond on this, plz.
why not model it exactly as it is in XML Infoset - so have children API 
but do not extend OMElement just duplicate it (AFAICT Document is not 
Element ...)


>On 5/31/05, jayachandra <> wrote:
>>Hi devs,
>>I have two suggestions regarding OMDocument
>>First - a trivial one:
>>It lacks an interface definition in the package and
>>a direct implementation class with name is coded in
>>the package. In line with how rest of the code is
>>arranged, I suggest we have in package an interface with name
>> listing out the setter and getter methods for
>>rootElement. And in the OMFactory interface we will add an extra
>>signature something like createOMDocument so as to enable other than
>>llom factory to be able to provide OMDocument implementation. Let the
>>implementation class in impl.llom package be named as
>>Second - this is a critical design issue:
>>Looking at the current OMDocument support I've realized that it
>>doesn't have a child navigation API. We might be doing away without it
>>as far as soap processing is considered. But without the child
>>navigation API in it, XMLInfoset can never be fully supported because
>>in an XML document other than the unique root element, at the same
>>level we can have several other nodes like documentation comments,
>>processing instructions, DTD element etc.
>>Enabling child API in OMDocument, implementation wise is not any
>>difficult. It can be just making it extend OMElement. Something like
>>public interface OMDocument extends OMElement ;
>>Semantically if the above looks confusing and weird (OMDocument being
>>an OMElement !!??!!), alternatively we can copy paste the already
>>coded child API functionality of OMElementImpl into OMDocumentImpl
>>letting OMDocument to stand on its own without extending any other
>>interface. Also, performance wise these changes are not going to add
>>any significant overhead.
>>Anticipating thoughts, ideas, suggestions

The best way to predict the future is to invent it - Alan Kay

View raw message