Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 29934 invoked from network); 17 Dec 2004 02:53:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 17 Dec 2004 02:53:46 -0000 Received: (qmail 97220 invoked by uid 500); 17 Dec 2004 02:53:43 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 97172 invoked by uid 500); 17 Dec 2004 02:53:43 -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: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 97158 invoked by uid 99); 17 Dec 2004 02:53:43 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from relay2.slt.lk (HELO relay2.slt.lk) (203.115.0.28) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 16 Dec 2004 18:51:56 -0800 Received: from extreme (localhost [127.0.0.1]) by relay2.slt.lk (8.12.10/8.12.10) with ESMTP id iBH0lFWO014827 for ; Fri, 17 Dec 2004 08:47:20 +0800 (SGT) Message-Id: <200412170047.iBH0lFWO014827@relay2.slt.lk> Reply-To: From: "Eran Chinthaka" To: Subject: RE: [Axis2] Namespace serialization problem Date: Fri, 17 Dec 2004 08:51:33 +0600 Organization: LSF MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <41C16589.60209@cs.indiana.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTjXJwuaK/rhIUdQDikCnCu19mGqwAhjL2g X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N >> >>Eran Chinthaka wrote: >> >>> >>> >>>>>Eran Chinthaka wrote: >>>>> >>>>> >>>>> >>>>>>OK , let me tell this from the scratch. >>>>>> >>>>>>No Namespace can exist without an Element. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>namespace can be attached to attribute too >>>>> >>>>> >>> >>>[Chinthaka] What I meant here was that, namespace must be *declared* in >>an >>>element. Yeah, its true it may not be used for an element localname, and >>>will be used only for attributes. >>> >>> >>> >>>>>>So lets remove createOMNamespace and one can only "declare" a >>namespace >>>>>> >>>>>> >>>>>in >>>>> >>>>> >>>>>>an OMElement. >>>>>> >>>>>>The next place we want to have OMNamespace is the OMELement creation >>>>>> >>>>>> >>>>>part. >>>>> >>>>> >>>>>>Here its bit tricky here. For me its like chicken and egg problem. >>>>>> >>>>>> >>>>>> >>>>>>How can we do this ? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>OmNamespace NS = builder.newNamespace(new URI("http://chinthaka.org", >>>>>"myPrefix"); >>>>>builder,newFragment(NS, "name") >>>>> >>>>> >>> >>>[Chinthaka] Alek, I didn't get this point. >>> >>> >>let me rework code fragment to demonstrate how this can be done - by >>separating namespace creation from element code is simple: >> >>// namespace is created >>OmNamespace NS = builder.newNamespace( >> new URI("http://chinthaka.org"),"myPrefix"); >> >>// later namespace is used to create element representing: >> >>// >> >>... >> >>OmElement el = builder.newElement(NS, "name") [Chinthaka] In this situation, in the constructor of the OMElement, we have to check whether the given OMNamespace is in the scope. If not, put it in the declared list. >> >> >>> >>> >>>>>>If we are not allowing to create an OMNamespace, then this should be >>like >>>>>>OMElement element = factory.createOMElement(parent); >>>>>>OMNamespace ns = element.declareNamespace("http://chinthaka.org", >>>>>>"myPrefix"); >>>>>>element.setNamespace(ns); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>too complicated and not intuitive >>>>> >>>>> >>> >>> [Chinthaka] Oops, I wonder why u say so. >>>We first define the element. Then set the namespace. Whats wrong with >>that >>>?? >>> >>> >>when you create element you want to give it name (missing in your >>example). i do not like that element may be in "intermediate" state when >>it has no name or no namespace but such "incomplete" element can be used >>- makes API harder to use. [Chinthaka] Sorry I've done a mistake. localName should be given. But not the namespace. Sorry for not putting ideas, correctly in to the paper :( Thankx, Eran Chinthaka >> >>> >>> >>>>>>within the declareNamespace(), we first check for a namespace, in the >>>>>>already declared list. If found return that or else create new one. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>OmNamespace used for declareNamespace must have prefix!=null >>>>> >>>>> >>> >>> [Chinthaka] Sorry what I meant here from declareNamespace() was that >>>declareNamespace(prefix,uri). Sorry abt that :( >>> >>> >>> >>>>>other possibility is that if it ns already declared it should be >>>>>exception but only if prefix is the same as of already existing >>namespace? >>>>> >>>>> >>>>> >>>>>>I think this will solve the problem. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>i am not sure about that. i think creating namespaces in factory is >>>>>better as they are really constants (value objects) so can be shared in >>>>>any XML tree even over multiple threads >>>>> >>>>> >>> >>> [Chinthaka] I think what u suggest is a global namespace table. >>> >>it is decided in builder/factory implementation - there can be many >>implementations >> >>>But still >>>we need to have namespace information within an element. >>> >>> >>by reference >> >>>I agree that even though this approach the extra global table, if one try >>to >>>declare the same namespace in two different places, he will get the same >>>object. Isn't it ? >>> >>> >>no need for global table if you do not need it. builder/factory can >>still do new OmNamespaceImpl() if it want. >> >>>I think that's good idea. But we have to make sure OMNamespace is >>immutable. >>> >>> >>that is exactly what i am trying to suggest :) >> >>> >>> >>>>> >>>>> >>>>>>Comments ?? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>main advantage of using immutable value objects as described in details >>>>>by Joshua Bloch in /Effective Java/: "C/lasses should be immutable >>>>>unless there's a very good reason to make them mutable/..../If a class >>>>>cannot be made immutable, you should still limit its mutability as much >>>>>as possible/." (see more in http://www.javapractices.com/Topic29.cjp >>and >>>>>i recommend reading this book) >>>>> >>>>> >>> >>> [Chinthaka] Thankx for the reference. :) >>> >>> >>> >>> >>it is good book for anybody designing Java API or library. >> >>thanks, >> >>alek >> >>>Thankx, >>>Eran Chinthaka >>> >>> >>> >>>>>thanks, >>>>> >>>>>alek >>>>> >>>>>-- >>>>>The best way to predict the future is to invent it - Alan Kay >>>>> >>>>> >>>>> >>> >>> >>> >>> >>> >> >> >>-- >>The best way to predict the future is to invent it - Alan Kay