Senaka, I would like to set aside for a moment the larger issues with copying that you mention, and just address a couple of your smaller questions.
You suggest that when attaching a tree one needs to merge the namespaces. I don't see why. Certainly, when the detached subtree carries the references to the namespaces that are used in the tree, when it is attached to a larger tree and that tree serialized, the namespace declarations may occur more than once. But this is allowed by the XML scope rules. Removing the redundant namespace references in some kind of merge might recreate the very problem that Kasun raises. To be correct after the merge, every reference to a redundant namespace reference that was merged would need to be replaced with a pointer to the corresponding namespace reference in the parent structure that was preserved. It is true that the extra namespace declarations may appear unsightly to the human reader. But they have no impact on an xml parser. Personally, I'm more concerned that preserving all the namespace prefixes that are in-scope when the node is detached will retain several prefixes that are not used in the subtree, e.g., the env prefix for the soap envelope. But, again, these may be unsightly to the human reader but they have no impact on an xml parser. I don't think I understand your comment about "it is the responsibility of the person who declares the namespace to free it". Maybe this is a reference to some earlier discussion. Perhaps this is related to something strange I see in the code today. The interfaces to axiom_element_create and axiom_element_set_namespace are a little peculiar and not consistent. In both, when a namespace is passed, they look to see if the namespace uri is already declared in a parent, and if so they use that namespace rather than the one that was passed. In axiom_element_create, it chooses to free the passed namespace if it was different from the one it found. This even though the caller will still have a pointer to the now freed namespace structure. In axiom_element_set_namespace, it leaves the passed namespace intact, even though the caller has no way of telling that the namespace was not used in the element and that the caller needs to free the namespace, creating the potential for a memory leak. Do you have any idea what the history is behind these different behaviors? Thanks, Bill -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 10:02 AM To: Apache AXIS C Developers List Subject: RE: Issue in using 'detach' for cloning Hi, A locally viable solution wouldn't solve all the issues with cloning Bill. Once we have this feature added, we'll simply have to address a new set of client requests bugs etc. coming after that. I believe this is viable at Kasun's end, but, not in Axis2/C. We have to figure out how to do these after cloning. 1. Rename/Delete namespaces 2. Add new namespaces and re-attach to original tree. 3. Add new namespace with same prefix but different uri to original sub tree. How are these possible? If you use detach, you have one big ease. That is, you only got to worry about namespaces. If you go for clone, you also got to worry about attributes etc. Thus, clone will be a deep copy of all references, and a serialize/de-serialize would be rather efficient than seeking and duplicating. At least because it all happens if one step without conditional expression evaluation. But, in the case of a detach you will rather only need to bother about namespaces which in return would be deep-copies. Also if you plan to add an attach method, you will have to merge child's namespaces into the parent through a comparison. I have great deal of doubt about shallow copies. Mainly because I remember seeing something like, "it is the responsibility of the person who declares the namespace to free it", which violates the whole idea. Please correct me if I'm wrong. Regards, Senaka > Samisa, I think what Kasun was saying is that detach, if it did not lose > the namespace references for the attributes, does work for him. When he > attaches the detached tree into a new larger tree, the detached tree needs > to keep valid namespace references for all of its nodes, even when the > parent node, Node A, does not already refer to those same namespaces. > > I presume, as well, if he needs to include the detached subtree into > several trees, a shallow copy works, as it preserves the information. > > Regards, > Bill > > -----Original Message----- > From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] > Sent: Friday, February 15, 2008 4:42 AM > To: Apache AXIS C Developers List > Subject: Re: Issue in using 'detach' for cloning > > Kasun Indrasiri wrote: >> >> >> On 2/15/08, *Samisa Abeysinghe* <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> Once you detach, how are you going to use the detached node? Attach >> to >> another tree? >> >> >> Samisa... >> >> >> Hi, >> After detaching the node from the original node, the detached node is >> attached to another node (say node A) as a child node. Node A, >> may or may not have the namespaces used in the detached node. > > OK, so current detach does not work for you. Would serialize sub tree > and then deserialize would be a viable option for you? > > Samisa... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
