[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Announcement: SAX Java Implementation (pre-release)
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|