RE: [jsr110-eg-disc] Re: QNames

[Glen Daniels <gd...@macromedia.com>]

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.

--Glen

Re: [jsr110-eg-disc] Re: QNames

[Roberto Chinnici <ro...@sun.com>]

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.