Sorry, i meant to address Ajith, not Eran  -  was a typo :-)

On 4/18/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
> On 4/18/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I guess this is another facet of the SOAP vs pure XML problem :). The reason
> > why we are not so keen on having an OMDocument is that it is just redundant
> > when it comes to SOAP message processing (except for a PI which we are happy
> > to skip:)).
> > IMHO you will probably need to reinstate the OMDocument if full infoset
> > support is needed!
> >
> 
> Eran,
> 
> 1. Given that we need to implement full infoset support, do we still
> think OMDocument and PIs are such bad things? :)
> 
> 2. As i mentioned, the StaxOMBuilder is already instantiating
> OMDocument on the START_DOCUMENT event. I hope you meant the same by
> "reinstating OMDocument"?
> 
> 3. What do you think about moving child node API from OMElement to
> OMNode and OMDocument implementing OMNode?
> 
> - venkat
> 
> >
> > On 4/15/05, Venkat Reddy < [EMAIL PROTECTED]> wrote:
> > > Before i talk about the problem, Eran, i see that we are still
> > > creating the OMDocument and setting the first ELEMENT_NODE as its
> > > rootElement. - isn't it?
> > >
> > > The problem as i understood:
> > >
> > > There are stuff other than root element (envelop) that need go as
> > > children into the OMDocument object. Currently this is not possible
> > > because OMDocument isn't designed to contain anything other than
> > > rootElement.
> > >
> > > Possible solutions:
> > >
> > > 1. Make OMDocument to extend OMNode, and move the addChild* methods
> > > from OMElement to OMNode. I think this is preferable becaus the
> > > addChild, getChild sort of methods seem more natural to OMNode than
> > > OMElement. OMElement can have addChildElement etc, if needed.
> > >
> > > 2. Make OMDocument to extend OMElement, but i think this is an
> > > overkill, because the Document object isn't really an XML element.
> > >
> > > I didn't understand why we need Object or OMContainer as parent. May
> > > be i'm missing something.
> > >
> > > - venkat
> > >
> > >
> > > On 4/12/05, Eran Chinthaka <[EMAIL PROTECTED] > wrote:
> > > > On Apr 12, 2005 12:58 PM, jayachandra <[EMAIL PROTECTED]> wrote:
> > > > > Hi devs!
> > > > >
> > > > > Currently OMNodeImpl has the data memeber 'parent' of type OMElement.
> > > > > This appears problematic. Because for document level comments (i mean,
> > > > > comments that are present outside the root element in the XML
> > > > > document) parent becomes OMDocument rather than OMElement. So better
> > > > > have the 'parent' data member as Object. And accordingly the return
> > > > > type of getParent will be Object. I hope this change will not break
> > > > > any existing code, will it???
> > > >
> > > > This will not break any of the code. But this will add some bad
> > > > things, IMHO, to code. For example, anything can be a parent of any
> > > > node, even a Text node.
> > > > That was the main reason why, we purposely made parent to an OMElement.
> > > >
> > > > I understand your concern, but ............
> > > >
> > > > And there is another question coming from me, is it necessary to
> > > > provice the ability to add comments to the Document which is even out
> > > > of the document element ??
> > > >
> > > > Making this available is of not that useful, but will add some weird
> > > > look to the code.
> > > >
> > > > We earlier had the concept of OMDocument, but later removed it.
> > > >
> > > > For your all information : These days all the Sri Lankan people have
> > > > gone home to celebrate  our Sinhalese new year festival. So, there may
> > > > be (including me), a deley in replying to the mails. :(
> > > >
> > > > Regards,
> > > > Chinthaka
> > > >
> > > > >
> > > > > Jaya
> > > > > --
> > > > > -- Jaya
> > > > >
> > > >
> > > > --
> > > >
> > --------------------------------------------------------
> > > > Eran Chinthaka
> > > >
> > >
> >
> >
> >
> > --
> > Ajith Ranabahu
>

Reply via email to