Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 50601 invoked from network); 25 May 2005 08:31:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 25 May 2005 08:31:37 -0000 Received: (qmail 35557 invoked by uid 500); 25 May 2005 08:31:19 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 35313 invoked by uid 500); 25 May 2005 08:31:16 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 35138 invoked by uid 99); 25 May 2005 08:31:15 -0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of chinthakae@gmail.com designates 64.233.170.197 as permitted sender) Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.197) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 25 May 2005 01:31:11 -0700 Received: by rproxy.gmail.com with SMTP id f1so108442rne for ; Wed, 25 May 2005 01:30:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:reply-to:from:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=fDRGdIIHrl8jWmeehe4ywVF0882YdTrNo+sFwB6VkaRyWs6aRKCN65Et9AhRpZEnFpth1zt9GEij4G9yH5VU2Hp4A8EZJUakS6J1rYX7Dv9PcAlZMi+3h9Ry6gwAhObZIroR9p+BWlW1dBdfBIolOI0JmzwLt2y3mJXA7fwh3Gs= Received: by 10.38.67.44 with SMTP id p44mr379889rna; Wed, 25 May 2005 01:30:59 -0700 (PDT) Received: from extremem ([220.247.220.47]) by mx.gmail.com with ESMTP id 59sm317939rnd.2005.05.25.01.30.57; Wed, 25 May 2005 01:30:59 -0700 (PDT) Message-ID: <00d601c56104$146a2030$0400000a@extremem> Reply-To: "Eran Chinthaka" From: "Eran Chinthaka" To: "Venkat Reddy" , , "Ajith Ranabahu" References: <57023d13050520042760afe748@mail.gmail.com> <008401c560dd$ca4510d0$0400000a@extremem> Subject: Re: [Axis2] Proposal for adding a method in OMElement API. Date: Wed, 25 May 2005 14:27:57 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 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 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