Lately I've been playing around with XNI to make various
kinds of configurations. While the framework is very very
cool, I have seen a few of the "warts", if you will, and
would like to make some changes to the interfaces. So I'm
posting my wish list here to see what other people think.
(+) Define Filter Interfaces
Currently, we have xxxHandler and xxxSource interfaces
but without an equivalent xxxFilter interface, it makes
it rather hard to construct parser pipelines generically.
Therefore, I would like to add the following interfaces:
public interface XMLDocumentFilter
extends XMLDocumentHandler, XMLDocumentSource { }
public interface XMLDTDFilter
extends XMLDTDHandler, XMLDTDSource { }
public interface XMLDTDContentModelFilter
extends XMLDTDContentModelHandler, XMLDTDContentModelSource { }
These interfaces have no body but would simplify the
construction of parser pipelines in a generic fashion.
If we had a document filter interface then we could
define a document scanning pipeline as the following:
XMLDocumentScanner
XMLDocumentFilter*
XMLDocumentHandler
Without the filter interface, it makes it harder to
build a dynamic parser configuration.
(+) Add Getters for Setters in Parser Configurations
We have setters for handlers, etc. in the parser config
interface but no way to query them once they're set. I
think this is a deficiency and we should add the following
methods to the XMLParserConfiguration interface:
public XMLDocumemntHandler getDocumentHandler();
public XMLDTDHandler getDTDHandler();
public XMLDTDContentModelHandler getDTDContentModelHandler();
public XMLErrorHandler getErrorHandler();
public XMLEntityResolver getEntityResolver();
public Locale getLocale();
(+) Add Non-Normalized Value to Internal Entity Decl
James Clark recently released a really cool tool that can
read in a DTD and by analyzing the way parameter entities are
nested within other parameter entities (and then used in
content models), can output a RelaxNG grammar that separates
the pieces appropriately. So I started thinking about if we
could do the same thing in XNI.
Earlier we re-arranged the XMLDTDContentModelHandler methods
to make it easier to detect where parameter entities are used
within a content model. However, the internalEntityDecl
method on the XMLDTDHandler interface only provides you the
normalized value of the entity. Therefore, I think we need
to add another parameter to this method to pass the non-
normalized value. For example:
public void internalEntityDecl(String name, XMLString value,
XMLString nonNormalizedValue)
throws XNIException;
(-) Remove the Attribute Entity Information
I would like to remove the methods for adding entity
reference information from the XMLAttributes interface.
I think that this information is redundant considering
that we already store the non-normalized value of the
attribute value. And we could provide a utility class
that helps users break the attribute's value into its
component parts.
The inclusion of this data unnecessarily complicates
the XMLAttributes interface and its use is limited. (At
the moment, we don't use it at all. The idea was to be
able to support the DOM's attribute nodes containing
nested entity reference nodes. However, an attribute in
the DOM doesn't take into account the non-normalized
value; it only stores the normalized value and the
entities only apply to the non-normalized value.)
(?) Should Handler/Source/Filter Be in Same Package
Does it make sense to have the XMLDocumentHandler,
XMLDocumentSource, and XMLDocumentFilter in separate
packages? Or should they live in the same package?
Comments and additional wish-list items would be
appreciated.
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
