Re: [xml] new SAX2 API

On Thu, Oct 02, 2003 at 10:44:57AM +1000, Malcolm Tredinnick wrote:
On Thu, 2003-10-02 at 08:10, Daniel Veillard wrote:
Can somebody gie me an example of something that is an "error", but not
"fatal"? At least during parsing, I thought that all errors were fatal.

  No, no, the spec makes them quite different.


    [Definition: A violation of the rules of this specification; results
    are undefined. Conforming software may detect and report an error
    and may recover from it.]
fatal error

    [Definition: An error which a conforming XML processor must detect
    and report to the application. After encountering a fatal error,
    the processor may continue processing the data to search for further
    errors and may report such errors to the application. In order to
    support correction of errors, the processor may make unprocessed
    data from the document (with intermingled character data and markup)
    available to the application. Once a fatal error is detected, however,
    the processor must not continue normal processing (i.e., it must not
    continue to pass character data and information about the document's
    logical structure to the application in the normal way).]

  example of error
  - <?xml version="1.2"?>
  - non-deterministic content model in DTDs ((a , b) | (a , c))
  - <!DOCTYPE SYSTEM "foo.xml#bar">
  - etc ...

And all of the errors I can think of from each of the xmlErrorDomain
(below) values looks fatal (except maybe some HTML things, if the
library was operating in a kind of tag soup mode).

  Well In most case the associated specs have definitions for the
equivalent of error vs. fatal error. This is common practice inherited
from the IETF and now embedded in all W3C specs.

Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]