axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
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 ...)
http://www.w3.org/TR/xml-infoset/#infoitem.document

alek

>Thanks
>Jaya
>
>On 5/31/05, jayachandra <jayachandra@gmail.com> wrote:
>  
>
>>Hi devs,
>>
>>I have two suggestions regarding OMDocument
>>
>>First - a trivial one:
>>---------------------------
>>It lacks an interface definition in the package org.apache.axis.om and
>>a direct implementation class with name OMDocument.java is coded in
>>the o.a.a.om.impl.llom package. In line with how rest of the code is
>>arranged, I suggest we have in o.a.a.om package an interface with name
>>OMDocument.java 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
>>OMDocumentImpl.java
>>
>>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
>>
>>Regards
>>Jaya
>>
>>    
>>
>
>
>  
>


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


Mime
View raw message