Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: <3BBA2757.7D78A46C@sun.com>
Date: Tue, 02 Oct 2001 13:45:11 -0700
From: Roberto Chinnici <roberto.chinnici@sun.com>
Organization: Sun Microsystems, Inc.
MIME-Version: 1.0
To: Glen Daniels <gdaniels@macromedia.com>
CC: "'jsr110-eg-disc@yahoogroups.com'" <jsr110-eg-disc@yahoogroups.com>,
        "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>,
        "'jsr-101-experts@eng.sun.com'" <jsr-101-experts@eng.sun.com>
Subject: Re: [jsr110-eg-disc] Re: QNames
References: <4F47DCFADC8DD5118D2B00508B952D9645AE2A@salsa.allaire.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Glen,

How about making QName a concrete, final class with *immutable*
instances much like java.net.URI in JDK 1.4.0? It doesn't make
much sense to me to modify a QName after it's been created.

Here's what it would look like (basically, it's Rahul's version,
made concrete, final and with setters removed):

public final class QName implements Serializable {
    public QName(String localPart) { this("", localPart); }
    public QName(String namespaceURI, String localPart) {...}
    public String getNamespaceURI() {...}
    public String getLocalPart() {...}
    public int hashCode() {...}
    public boolean equals(Object obj) {...}

    private String namespaceURI;
    private String localPart;
}

We could also think of having it implement Comparable (if we can
agree on some conventional ordering for QNames -- of course,
the obvious one comes to mind).

The only other caveat I have is that I'd like to rule out null as
a valid value for the namespace URI and use the empty string
instead. This way we don't have to write "if (nsURI != null)"
all over the place. Moreover, no meaningful distinction can
be made between a null and an empty namespace URI in
an immutable QName.

In the same spirit, I'd like constructors to throw an exception
if they're passed a null local part, since that's not a valid
NCName value.

Roberto


Glen Daniels wrote:

> Hi Rahul:
>
> >   Yes. We should have one standard QName class. I can take the
> >   action item to sync with all JAX* JSRs and WSDL4J, and propose
> >   a single QName class. All JSRs can then reference this common
> >   QName class.
>
> Yep, that sounds perfect.
>
> >   To start, we should discuss what should be in this QName class.
> >
> >   Here is the JAX-RPC QName class:
> >
> >   package javax.xml.rpc.namespace;
> >   public abstract class QName implements Serializable {
> >     public abstract String getLocalPart();
> >     public abstract void setLocalPart(String localPart);
> >     public abstract String getNamespaceURI();
> >     public abstract void setNamespaceURI(String namespaceURI);
> >     public abstract int hashCode();
> >     public abstract boolean equals(Object obj);
> >   }
>
> The Axis QName class has almost exactly that signature, except that it's not
> abstract and has the following constructors:
>
>     public QName()
>     public QName(String namespace, String localPart)
>     public QName(String qName, Element element)
>
> The first is for deserialization, the second is the "common" one, the third
> is a utility for making a QName from a tag name by using prefix mappings
> from the given DOM element.
>
> The WSDL4J version is Cloneable and also has a couple other APIs.
>
> I think the version from JAX-RPC should be good as a core class, with
> constructors.  Then we can build utility stuff for particular projects
> around that.
>
> >   The javax.xml.QName seems a better packaging. Another issue
> >   relates to whether this should be an abstract class or an
> >   interface. If we are keeping this class common, we can as
> >   well provide QName implementation.
>
> Why not just make it a non-abstract class and provide an implementation?
> It's simple enough that I don't see much reason to add the extra layer.
> That way all Java QNames are comparable and interchangeable.