Next Round

Tyler Baker tyler at
Thu Jan 21 03:22:57 GMT 1999

Don Park wrote:

> >3. Namespace Support
> How about  this?
> public interface NamespaceHandler {
>     public void startNamespace(Namespace ns);
>     public void endNamespace();
> }
> public interface Namespace {
>     public String getPrefix(String qname);
>     public String getURI(String qname);
> }
> Namespace implemention is responsible for keeping track of inheritance.
> Again, we can use setDocumentHandler to automatically check for
> NamespaceHandler implementation.
> For efficiency sake, we might also require that if NamespaceHandler is
> supported then all names (tag name, attribute name, namespace prefix and
> URI) should be 'interned'.

This is a good idea.  I have been thinking alot about how to implement this in
the native parser interface for an XML Parser I have written in a manner that is
efficient yet easy to use.  My recommendation to SAX is a little more radical.
In this sense Parser should not be extended but instead you now have an
additional NamespaceParser which is of its own type.  This is the clean way of
doing things since you cannot dynamically know if a SAX Parser implementation
also supports namespaces.  Maybe there is a way, but it would be a pain to
handle.  Plus a lot of XML parsers do not have namespaces built in and may never
have namespaces support.  In this case some sort of Namespaces filter could be
used to supplement the native support for namespaces that the parser does not

First, we will need to define a new type, namely Name.

public interface Name {
  String getPrefix();
  String getLocalName();
  String getQualifiedName();
  String getNamespace();
  String getExpandedName();
  Name clone();

Then change the startElement method to:

void startElement(Name name, AttributeList attributes);

and the endElement method to:

void endElement(Name name);

also the AttributeList interface may need to be changed a bit:

the method getName() will need to be changed from:

String getName(int index);


Name getName(int index);

Also for the getType(String name) and getValue(String name) methods will need to
be changed and made to:

String getTypeByQualifiedName(String prefix, String localName);
// prefix + ':' + localName
String getTypeByQualifiedName(String qualifiedName);

String getTypeByExpandedName(String namespace, String localName);
// namespace + ':' + localName
String getTypeByExpandedName(String expandedName);

String getValueByQualifiedName(String prefix, String localName);
// prefix + ':' + localName
String getValueByQualifiedName(String qualifiedName);

String getValueByExpandedName(String namespace, String localName);
// namespace + ':' + localName
String getValueByExpandedName(String expandedName);

Note: these method names are quite long and could be improved but I do not have
any better ideas off of the top of my head for now.

Names could lazily return the String values of the prefix, local name, qualified
name, namespace, and expanded name.  For startElement and endElement the parser
itself could implement Name as Names would be fail fast.

For the attribute method Name getName(int index) a new name would need to be
created, or at least you could not cache those Name objects for resuse until the
startElement method returns.

>From my initial thoughts on this, this would allow applications to get at both
the non-namespace processed values as well as the processed namespace values.
For parsing an XML Document into a DOM tree, preserving the true document
structure is very necessary and who knows, maybe the DOM will do something like
this later down the line so you can get at element names in a variety of ways.

One last nidpick...  Should SAX ignore treat namespace declaration attributes as
part of the AttributeList (having namespace declarations declared as attributes
is one of the many things I detest about "Namespaces in XML" as it makes things
very, very, very, very, very sloppy and unclean to deal with like in this
particular case) or else pretend they are not really there.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list