[Glen]
I'm not clear why you didn't derive ValidationException from SAXParseException. I know the locator is already present in FOPException, but absent the subclass from SAXParseException, it ends up being a "different" Locator object, i.e., user code that would handle a SAXParseException can't handle this FOPException. Perhaps just a nitpick, but I see a long-term advantage in having our ValidationExceptions subclass SAXParseException if possible.
Sometime when a PropertyException is thrown (f.ex during evaludation of a relative numeric) the name of the property and the location is not available. In the patch I've added a catch in PropertyParser which add the property name and location information to the PropertyException and rethrows the augmented exception. SAXParseException keeps the location information private so it is not possible to change the location info after a SAXParseException is thrown. Other than that, the hierarchy could also have been rooted in SAXParseException.
(Namely, if an embedded user of FOP wished to report both parsing and validation errors to the user in the same manner--a plausible scenario--it would be convenient to have ValidationException subclass SAXParseException.)
ValidationException and SAXParseException both have SAXException as a parent, so a user can catch SAXException to deal with the different exception in a uniform manner.
regards, finn
