SAX2: Namespace Processing and NSUtils helper class

[Hill, Les]

On a related topic:
I like what Ray is saying because it lays the foundation for a missing
higher level abstraction to SAX.  What we and just about everyone else using
SAX have developed is an in-house HandlerBase dispatcher class that acts as
a giant switch, doling out events based on element names (a common pattern
in many different types of processes).  Now with namespaces, we effectively
have a two-layer! switch that will be continually developed independently in
the XML community!

To address this, I propose adding a higher level utility provided as part of
SAX2 named ElementDispatcherBase.  For those who have philosophical
differences with this approach, I am proposing that we compliment the
current monolithic handler feature of SAX.  The interfaces required would be
along the lines of:

public interface SAX2ElementHandler
{
	public void startElement(Attribute[] attrs) throws SAXException;
	public void endElement() throws SAXException;
}

public interface SAX2DefaultElementHandler
{
	public void startElement(String nameSpace, String elementName,
Attribute[] attrs) throws SAXException;
	public void endElement(String nameSpace, String elementName) throws
SAXException;
}

public interface SAX2ElementDispatcher extends SAX2DocumentHandler
{
	/**
	 * Default element handler, effectively the SAX status quo
	 */
	public void addDefaultElementHandler(SAX2DefaultElementHandler
hndlr);

	/**
	 * Handle element in all namespaces
       */
	public void addElementHandler(String elementName, SAX2ElementHandler
hndlr);

	/**
	 * Handle element in this namespace only
       */
	public void addElementHandler(String nameSpace, String elementName,
SAX2ElementHandler hndlr);

	public void removeDefaultElementHandler(SAX2DefaultElementHandler
hndlr);
	public void removeElementHandler(String elementName,
SAX2ElementHandler hndlr);
	public void removeElementHandler(String nameSpace, String
elementName, SAX2ElementHandlerNS hndlr);
	/* remove by name only? */
}

The normal use of the interfaces should be straightforward.  There maybe
some concern over elements that are closely related and have almost
identical processing that is differentiated by name.  The standard Java
technique of using inner classes to register unique, one-liner,
mini-handlers would work well in most of those cases; or the default handler
could be invoked -- the equivalent of today's big switch (or hopefully,
home-grown dispatcher :).

Note that handlers are removed by name as well as object-identity, allowing
for the handling multiple differently identified elements by the same
handler [if you removed by object-identity only, and you had registered for
multiple elements, removal would probably not do the right thing].

Regards,

Les Hill
Senior Architect
Excelergy

=======================================================
Excelergy is hiring Java/C++ XML developers, all levels
   send resume (and mention me :) to jobs at excelergy.com
=======================================================



Ray Waldin writes:
>For example:
>
><element1 xmlns="uri1" xmlns:p2="uri2">
>  <ns2:element2 foo="bar" xmlns:p3="uri3" p3:whiz="bang"/>
></element1>
>
>would produce the following stream of events:
>
>  startDocument();
>  startNamespace( prefix=null, uri="uri1" );
>  startNamespace( prefix="p2", uri="uri2" );
>  startElement( name="element1", attrList=null );
>  startNamespace( prefix="p3", uri="uri3" );
>  startElement( name="p2:element2", attrList={ foo="bar", p3:whiz="bang"
});
>  endElement( name="p2:element2" )
>  endNamespace( prefix="p3" );
>  endElement( name="element1" );
>  endNamespace( prefix="p2" );
>  endNamespace( prefix="p1" );
>  endDocument();
>
>Simple management of these namespaces can be provided for in some helper
class like the
>NSUtils example, and can even be handled automatically for the most part in
a new
>HandlerBase2 class, but this decision of how (or whether) to handle
namespaces could be
>left to the application author.  Anyone else feel this way?

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)