Announcement: SAX Java Implementation (pre-release)

[Tyler Baker]

David Megginson wrote:

> James Clark writes:
>  > David Megginson wrote:
>  >
>  > > I have put together a new, beta version of SAX with quite a few
>  > > changes
>  >
>  > This looks good.  I have some nits:
>
> Actually, these are very good points, all of which deserve detailed
> answers, and several of which are so self-evidently correct that I'd
> like to make the changes right away.
>
> Could anyone implementing SAX (on either the parser or application
> side) please read through this entire reply?  There are several points
> where I'd appreciate feedback.
>
>  > 1. Why has a SAX prefix been added to all classes?
>
> There are a few benefits to this decision:
>
> 1. Programmers can import SAX classes into their own namespaces
>    with less danger of collision (they will often have their
>    own "Parser" and "DocumentHandler" classes).  Experienced programmers
>    might snort at this, but I have had several messages from people
>    who couldn't understand why their code wasn't compiling properly.

This is very much more evident I have found with method naming collisions than
actual class naming collisions.  The class naming collisions can be fixed by
explicitly naming the entire package qualified name for classes which collide.
With interfaces there is no mechanism to do this.  If you have a class which
implements two interfaces that may have the same method declarations and
signature, then you are pretty much SOL as far as figuring out what should be
returned.  For example java.security.Principal defines String getName() which
could be applied to all sort of contexts in a Java/XML application that has
security implications.  For the interfaces for the object based parser I have
written, I for the element interface, instead of declaring String getName() I use
the more cumbersome String getElementName().  In the long run this sort of
redundant naming will make your design challenges a little easier I feel.

> 2. I save a lot of time that I would have had to spend helping people
>    who still had the old Java SAX classes somewhere on their
>    CLASSPATH.

You should not design around people being sloppy with installations.  Perhaps you
could have use InstallShield or a script which would install the latest SAX and
desinstall the older SAX versions, or at the very minimum change the CLASSPATH so
this problem does not happen.

> I thought for a while about this -- SAXDocumentHandler also provides
> only partial document information, so I was thinking that we would
> have something like
>
>  > 7. Is the first character on the line at column 0 or column 1? (GNU
>  > Emacs says column, but others say column 1.)  The docs need to make
>  > this clear.
>
> The first character is in column 1.  I will fix the docs.

It would be nice for programming purposes (at least for Java, C, and C++) if
columns and rows had their index starting at 0.

Tyler


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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe 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)