Hi Venkat,
1.Well, OMDocument is not a bad thing. ultimately we need to expose it to the user. The important thing is that this OMDocument should not be visible to the user in the SOAP API. So as far as the SOAP API's are intact I have no objection in putting up the OMDocument.
2. Not really. Even though the OMDocument is there, it is not returned to the user in any case. The builder returns the document element , not the document object. What I mean by saying re-instating is showing up the OMDocument in the API.
3. Hmmmm. That I have to think about. I am not sure what kind of impact it will have. However for pure accuracy, extending OMnode to make the OMDocment is the correct thing.
On 4/18/05, Venkat Reddy <[EMAIL PROTECTED]> wrote:
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
>
--
Ajith Ranabahu
