On 4/26/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > Hi, > > > > > I too feel Option2 is good. But instead of what Ashu was saying to > > throw an OMException in case of Body already being present, I would > > say we add a warning or debug log info sort of thing and still proceed > > with detaching and adding the new body. > > Great. One more thing. We are now changing the functionality of the detach > method too. Earlier detach() not only detached the node from the tree, but > also discard the events thrown within that. > Meaning, say > > <a> > <b> > <c> > <d> > </b> > <e> > </a> > > If the parser's cursor is @ b, when we say b.discard() it will proceed the > parser till end of b and will not build the object structure. That means we > lose c and d altogether. > > So now what we will be doing is we have two methods, discard() and detach(). > > Discard() will do the above functionality. But detach() will just disconnect > b from a and adjust the other links.
How would you adjust the links... Will <c> and <d> be now children of <a> acting as siblings to <e>? or choose one amongst the children candidates to act as the parent of the remaining children. The first case appears intuitive somehow but then, all the child nodes statures get elevated by one level with the dissolving of parent. As a side effect, if you want to restrict some namespaces prefixes etc only to the scope of <c> and <d>, they either now become global if we want to keep the order of adjustment O(1) or otherwise this operation complexity should become O(no. of child nodes of <b> ). Do you see a use case anywhere that would need this 'dissolving' <b> kind of functionality. I'm just inquiring. Bye Jayachandra -- -- Jaya
