[XNI] Remaining Issues

[Andy Clark <an...@apache.org>]

I think that we need to resolve the following issues
before declaring XNI final and version it at 1.0:

* Augmentations

Why do we use the method name "removeAll<Things>" in
other places but use "clear" on this interface?

* NamespaceContext

What about the question regarding whether this should
be an interface or a class? Did we resolve this? and
implement the resolution?

Again, we use the method name "reset" here instead of
something that matches the rest of the API.

* XMLAttributes

Right now we implement this by creating an impl of
Augmentations for each attribute. Should this object
be set by the application? It doesn't seem to match
otherwise.

* XMLDocumentFragmentHandler

Previously, I thought that we should communicate a
list of the declared entities to the startDocument-
Fragment call. However, once we added the XML-
ResourceIdentifier interface to all of the start
entity calls, this change is no longer needed.

 From first glance, it looks like everything is in
order. But we should double-check that the method
prototypes in this interface match those found in
the XMLDocumentHandler interface -- except for the
XMLDecl and DoctypeDecl, of course.

* XMLDocumentHandler

The document source setter and getter should be
moved to the XMLDocumentFilter interface. The end-
points don't need to know their source -- only the
stages in the middle (i.e. filters) do.

Moving these methods cleans up the interfaces,
removes the dependency on the xni.parser package,
and shouldn't actually require us to change any
of our existing code *unless* the filter components
implement the source and handler interfaces instead
of the filter interface. But either way, it's an
easy change.

* XMLDTDHandler & XMLDTDContentModelHandler

Same comment as the XMLDocumentHandler.

* XMLLocator

I was surprised to find setters on this interface.
I know that we want a fully read-write framework but
this doesn't make much sense. Does the parser jump
around in the stream when the application sets the
line and/or column number? No. But it *feels* that
way having these methods.

The locator interface allows location information
to be reported to the application. This information
changes as the scanner (the only component that
should be changing this information) moves along.
The application, holding a reference to this
interface, queries the information any time during
the parsing of the document.

If the XMLLocator were passed at each callback,
then I would have named it XMLLocation and added
the setter methods. But that's not the way this
interface works. Therefore...

I think we should remove the setter methods.

                        * * *

And those are my comments on the the contents of the
xni and xni.parser packages. I haven't reviewed the
other packages, yet. Is it the intention to finalize
those packages as well?

Anyway, I would like to get these things fixed before
we declare XNI as version 1.0.

Comments?

-- 
Andy Clark * andyc@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org