axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: [jsr110-eg-disc] Re: QNames
Date Thu, 04 Oct 2001 18:58:29 GMT

+1

This looks good to me.  I'd suggest that it be valid to do this, though:

  QName q = new QName(null, "local");

...which is equivalent to:

  QName q = new QName("", "local");

So how do we move forward and get this into JAXP (?) as soon as possible?

--Glen

> -----Original Message-----
> From: Roberto Chinnici [mailto:roberto.chinnici@sun.com]
> Sent: Tuesday, October 02, 2001 4:45 PM
> To: Glen Daniels
> Cc: 'jsr110-eg-disc@yahoogroups.com'; 'axis-dev@xml.apache.org';
> 'jsr-101-experts@eng.sun.com'
> Subject: Re: [jsr110-eg-disc] Re: QNames
> 
> 
> 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.
> 

Mime
View raw message