Appendix A. SAX2 API SummaryThis appendix provides a quick reference to each of the SAX2 APIs presented in this book. It shows API signatures and provides a brief overview for each interface, class, and exception in alphabetical order. Full documentation for these APIs is available for you to download or browse online at the SAX web site (http://sax.sourceforge.net/), and it should also be available with documentation for your SAX parser. A.1. The org.xml.sax PackageThe org.xml.sax package holds the interfaces and exceptions that are at the core of SAX, including some deprecated SAX1 APIs. A.1.1. The AttributeList InterfaceThis SAX1 interface is not used in SAX2; the Attributes interface, which supports namespace identifiers, is used instead. For more information, refer to Section 5.2, "SAX1 Support " in Chapter 5, "Other SAX Classes".
A.1.2. The Attributes InterfaceThis interface groups all the attributes associated with a given element in the ContentHandler.startElement() call. Attribute characteristics are frequently accessed using an indexed access model, though you can also determine the index, type, or value of an attribute given XML 1.0-style (qName) or namespace-style (uri, localName) versions of its name. For more information, refer to Section 2.3.3, "The Attributes Interface " in Chapter 2, "Introducing SAX2".
A.1.3. The ContentHandler InterfaceThis is the primary SAX2 handler interface, which is used in almost all applications. For more information, refer to Section 2.3.4, "Essential ContentHandler Callbacks" and Section 2.6.4, "ContentHandler and Prefix Mappings", both in Chapter 2, "Introducing SAX2", as well as Section 4.1.1, "Other ContentHandler Methods " in Chapter 4, "Consuming SAX2 Events".
A.1.4. The DocumentHandler InterfaceThis SAX1 interface is not used in SAX2; the ContentHandler interface, which reports namespace identifiers and scopes as well as skipped entities, is used instead. For more information, refer to Section 5.2, "SAX1 Support " in Chapter 5, "Other SAX Classes".
A.1.5. The DTDHandler InterfaceThis interface is used to report information that is useful to some SGML-derived applications. For more information, refer to Section 4.3.2, "The DTDHandler Interface " in Chapter 4, "Consuming SAX2 Events".
A.1.6. The EntityResolver InterfaceThis interface encapsulates a strategy for resolving public or system identifiers for parsed entities into data that a parser will read. It is commonly used to ensure that local copies of DTDs are used, instead of DTDs accessed across a network link that may be saturated or unavailable. It can resolve general entities, used to store non-DTD parts of a document in separate storage units. For more information, refer to Section 3.4, "The EntityResolver Interface" in Chapter 3, "Producing SAX2 Events".
A.1.7. The ErrorHandler InterfaceThis interface encapsulates a strategy for handling different kinds of errors. Parsers use its methods when reporting errors, and have default policies that are used if the application's strategy doesn't result in throwing an exception. Applications can benefit from sharing the same mechanism to report their own errors. Implementations typically use the problem's severity to choose first whether to emit a diagnostic, and then whether to throw the parameter (to terminate processing) or return (to continue processing). For more information, refer to Section 2.5.2, "ErrorHandler Interface" in Chapter 2, "Introducing SAX2".
A.1.8. The HandlerBase InterfaceThis SAX1 class is not used in SAX2; the org.xml.sax.helpers.Defaulthandler class, which supports SAX2 features, is used instead. For more information, refer to Section 5.2, "SAX1 Support " in Chapter 5, "Other SAX Classes".
A.1.9. The InputSource ClassThis class is used to encapsulate entities for consumption by an XMLReader (or a SAX1 Parser). Applications should make every effort to provide a usable system identifier (an absolute URI, rather than null). This will ensure that relative URIs can be properly resolved so that diagnostics are meaningful. Given that identifier, SAX parsers can do the rest, possibly with assistance from an EntityResolver. For more information, refer to Section 3.1.2, "The InputSource Class" in Chapter 3, "Producing SAX2 Events".
A.1.10. The Locator InterfaceAn event producer may invoke the ContentHandler.setDocumentLocator() call to provide one of these objects. It may then be used inside event callbacks, until the final ContentHandler.endDocument() call, to determine the location of the data that triggered the event. A common use is to figure out the base URI used to resolve relative URIs found in document content. This is true even when xml:base attributes have been used to override the real base URI of the document. Another common use is to construct SAXParseException objects to construct application-level diagnostics. For more information, refer to Section 4.1.2, "The Locator Interface " in Chapter 4, "Consuming SAX2 Events".
A.1.11. The Parser InterfaceThis SAX1 interface is no longer used in SAX2; the XMLReader is used instead. For more information, refer to Section 5.2, "SAX1 Support " in Chapter 5, "Other SAX Classes".
A.1.12. SAXExceptionThis is the base SAX exception class. It can wrap another exception, and (like most exceptions) a descriptive message. For more information, refer to Section 2.5.1, "SAX2 Exception Classes" in Chapter 2, "Introducing SAX2".
A.1.13. SAXNotRecognizedExceptionThis exception is used to report that the identifier for a feature flag, or parser property, is not recognized. When this doesn't indicate a mistyped identifier, it means that the parser isn't exposing that particular information. For more information, refer to Section 2.5.1, "SAX2 Exception Classes" in Chapter 2, "Introducing SAX2".
A.1.14. SAXNotSupportedExceptionThis exception is used to report that while the identifier for a feature flag, or parser property, was recognized, setting the value was not practical. For example, read-only values can't be changed to nondefault values, handler properties need to implement the appropriate interface, and some values can't be changed while parsing, or accessed except while parsing. For more information, refer to Section 2.5.1, "SAX2 Exception Classes" in Chapter 2, "Introducing SAX2".
A.1.15. SAXParseExceptionThis type of SAXException is reported to the ErrorHandler, and adds information that is useful for locating (and hence fixing) problems in input text. That information may include the line and character offset in the entity being parsed, the entity's URL, and any public identifier associated with the entity. When used to report application-level errors, any exception caused by problematic data can be encapsulated, and associated with such Locator information to help pinpoint problematic input data. It's safe to provide null Locator or Exception objects. For more information, refer to Section 2.5.1, "SAX2 Exception Classes" as well as Section 2.5.3, "Errors and Diagnostics", which are both located in Chapter 2, "Introducing SAX2".
A.1.16. The XMLFilter InterfaceThis interface encapsulates the notion that one XMLReader may process the output of another one before delivering it. The XMLFilterImpl helper class is substantially more interesting, since it does the real work and can be used in a postprocessing mode as well. For more information, refer to Section 3.5.4, "The XMLFilter Interface" in Chapter 3, "Producing SAX2 Events".
A.1.17. The XMLReader InterfaceA SAX2 "parser" will normally be packaged as an implementation of this interface. Such a parser often takes XML text as input, though it need not. Some parsers need a DOM Document as input, and others parse non-XML text and report it as if it were XML, to leverage the SAX event processing model. For more information, refer to Section 3.1.1, "The XMLReader Interface" in Chapter 3, "Producing SAX2 Events". For quick reference to the standard SAX2 feature and property identifiers, refer to Section 3.3.2, "XMLReader Feature Flags" and Section 3.3.1, "XMLReader Properties", both in Chapter 3, "Producing SAX2 Events".
Copyright © 2002 O'Reilly & Associates. All rights reserved. |
|
|