Venkat Reddy wrote:
We can remove the namespace only if it is found in its own hashmap. So
no problems with parent's stuff. For its children, the namespace is
gone forever, if they are only storing incremental additions of
namespaces, but then thats what the user asked for, right?
my recommendation (memory wise!) - do not use hashmap and optimize for
common case which is *few* namespace declarations ... in future if it
ever comes up as problem there can be some logic to create hashmap if
element has more than N namespaces or use some optimized storage/lookup
structures but i would do it only when profiler shows it to be hot spot ...
alek
-Venkat
On 5/25/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Wait wait, we are missing something here.
Remember we have to think about the memory foot print as well. AXIOM is all
about memory and performance.
If we copy parent's namespace stack to children, we are wasting memory.
Isn't it. I agree that for us to better implement this remove namespace that
is a good solution. But if you think about the common case, this is utter
waste of memory.
<a>
<b>
<c/>
</b>
</a>
Think: each element defines 10 namespaces, in your suggested approach, we
will ended up with 60 hashmap elements. (10 from a, 20 from b and 30 from
c). But the current implementation will have just 30 entries + just object
references to the others.
Plus, even by doing this, will not solve the problem. What if you have some
attributes with the namespace you gonna remove. We have to change them as
well.
I agree that removeNamespace should be supported, but I have still no GOOD
idea about, how to do it.
Comments/Suggestions ?
Chinthaka
----- Original Message -----
From: "jayachandra" <[EMAIL PROTECTED]>
To: <[email protected]>; "Eran Chinthaka" <[EMAIL PROTECTED]>
Cc: "Venkat Reddy" <[EMAIL PROTECTED]>; "Ajith Ranabahu"
<[EMAIL PROTECTED]>
Sent: Wednesday, May 25, 2005 2:51 PM
Subject: Re: [Axis2] Proposal for adding a method in OMElement API.
Hi Eran et al,
Removing a namespace that child is using from a parent is certainly a
user fallacy and not able to handle that, I guess, is not any
compromise. If a user is following a API, he is expected to follow it
in its spirit, we can't help it. If that were a blocking compromise,
standardized SAAJ API will never have included the method, isn't it?
In my honest opinion, it's good to have this innocuous method.
Regards
Jaya
On 5/25/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi Venkat and all,
Okay - the usecase we have is the following method in SAAJ API on
javax.xml.soap.SOAPElement:
boolean removeNamespaceDeclaration(java.lang.String prefix)
We can't implement this without the undelying OM design catering to such
needs.
So here goes my +1 for implmenting this method on OMElement.
Regarding the uniqueness of prefix, i dont think it is an issue,
because every element has its own hashmap object for namespaces, and
for one prefix, there can be only one namespace in the scope, so
removal such namespace will not affect other elements or other
namespaces, i guess.
Every element has a namespace map. But if a child is using a namespace
declared in the parent, that child is pointing to the parent for that. So
if
we remove the namespace from the parent, we have some trouble.
I agree that u need a method like this for SAAJ impl. But how can we
compromise ?
When in doubt, lets vote :-)
Is it a joke ? ;) ;).
Regards,
- Chinthaka
- Venkat
On 5/25/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Hi all,
Well since our OMElementImpl keeps its own list of namespaces adding /
declaring a namespace would affect that Element only. if the reference
is
removed from the parent I don't see a problem with the children since
they
keep their own reference to the particular namespace. We ask for a
mandatory
namespace at creation, rememebr ?
The only thing that will not be elegant is the serialization.(I don't
see
a
problem though. The serializer handles it right and generates a
sematically
valid XML. That generated XML is not elegant)
So even though a non-used namspace does no harm (except serializing it
on
the declared element making the XML ugly) we can techinically remove it
without a problem.
On 5/25/05, Eran Chinthaka <[EMAIL PROTECTED]> wrote:
Hi Jaya and all,
I still find difficult to give you a method to remove namespaces.
Namespaces, once defined in an element, that will be used by all of
its
children. So if we try to remove a namespace, that will be a total
mess.
Isn't it ?
So I'm in doubt to give *any* of the methods to remove namespaces
.....
Regards,
Chinthaka
--
Ajith Ranabahu
--
-- Jaya
--
The best way to predict the future is to invent it - Alan Kay
