THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
A list of the XMLReader interface methods and specific details related to the Daffodil implementation are described below. See the XMLReader for more details on how an XMLReader should behave for particular functions.
ContentHandler | getContentHandler()Return the current content handler. |
DTDHandler | getDTDHandler()Return the current DTD handler. |
EntityResolver | getEntityResolver()Return the current entity resolver. |
ErrorHandler | getErrorHandler()Return the current error handler. |
boolean | getFeature(String name)Look up the value of a feature flag. The only two features that are implemented are http://xml.org/sax/features/namespaces and http://xml.org/sax/features/namespace-prefixes as required by the XMLReader interface. All other features shall throw a SAXNotRecognizedException. |
Object | getProperty(String name)No |
| properties are supported–this shall always throw a SAXNotRecognizedException. | |
void | parse(InputSource input)Parse data from an InputSource. The InputSource must be backed by an InputStream. The getByteStream() method must return non-null or an IOException shall be thrown. This shall call the custom parse(InputStream) method described below. |
void | parse(String systemId)This function is not supported. If called, this shall throw an IOException. |
void | setContentHandler(ContentHandler handler)Store the parameter in local state. This handler will receive the SAX events created by Daffodil. |
void | setDTDHandler(DTDHandler handler)Store the parameter in local state. Note that Daffodil will never use the DTDHandler except for when getDTDHandler() is called. |
void | setEntityResolver(EntityResolver resolver)Store the parameter in local state. Note that Daffodil will never use the EntityResolver except for when getEntityResolver() is called. |
void | setErrorHandler(ErrorHandler handler)Store the |
parameter in local state. The handler.fatalError() callback is used for Schema Definition Errors. The handler.warning() callback is used for Schema Definition Warnings. | |
void | setFeature(String name, boolean value)Set the value of a feature flag. The only two features that are implemented are http://xml.org/sax/features/namespaces and http://xml.org/sax/features/namespace-prefixes as required by the XMLReader interface. All other features shall throw a SAXNotRecognizedException. |
void | setProperty(String name, Object value)No properties are supported–this shall always throw a SAXNotRecognizedException. |
In addition the the above funtions, the following functinons are added to support other input types that Daffodil supports, which may allow for some optimizations.
void |
|
void |
Creates an InputSourceDataInputStream based on the array and a SAXInfosetOutputter (see below) and calls the DataProcessor parse method. |
SAXInfosetOutputter
The SAXInfosetOutputter is an implementation of the Daffodil InfosetOutputter interface responsible for converting InfosetOutputter events to SAX ContentHandler events. According to the SAX API, applications may register a new or different ContentHandler with the XMLReader in the middle of a parse, and the SAX parser must begin using the new handler immediately. Because of this, the SAXInfosetInputter must take the XMLReader as a parameter, and any time a SAX event is generated, it must call getContentHandler() on that parematerparameter. The definition for this class looks like:
...
Fortunately, the InfosetOutputter events correlate nicely to the InfosetOutputter events. Below is their mapping. Note that in some cases a single InfosetOutputter event may require calling multiple ContentHandler events.
| InfosetOutputter API | ContentHandler API |
|---|---|
| startDocument() | startDocument() |
| endDocument() | endDocument() |
startSimple() | startPrefixMapping() (optional, only when new namespace mapping is added) startElement(...) characters(...) |
| endSimple() | endElement(...) endPrefixMapping(...) (optional, only when new namespace mapping is removed) |
| startComplex() | startPrefixMapping(...) (optional, only when new namespace mapping is added) startElement(...) |
| endComplex() | endElement(...) endPrefixMapping(...) (optional, only when new namespace mapping is removed) |
| startArray() | no-op |
| endArray() | no-op |
Other functions in the ContentHandler interface will not be used.
...
The ContentHandler interface is used to receive and react to SAX XML events. In order to unparse data based on these events, Daffodil must unparse data based on the events that are received. However, the design of the unparser and InfosetInputter's behaves opposite to this–rather than receiveing events the unparser and InfosetInputter requests the next event. This is essentially push vs pull, or SAX vs StAX. To support unparsing based on SAX events, we must convert these push-style SAX events inout into the pull style events that Daffodil requires.
...
The newContentHandlerInstance() method allocates a Daffodil specific implementation of the ContentHandler interface that can be used to unparse data using the SAX API. Because the DataProcessor has all the actual logic for unparsing data, it must be passed into the ContentHandler implementation so that it can unparse data at the appropriate time. In addtionaddition, the ContentHandler must know where to unparse data to, so an OutputStream is also provided as a parameter. The implementation for this function looks something along the lines of the following:
...