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
