XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Error and Fatal Error

Thanks Mukul for these relevant qutes from the spec. 
 
"errors and MAY report such errors to the application."
 
so far so good.
But the next two sentences, to someone like myself trying to interpret the
spec, look like they are contradictory. (Perhaps the reason parsers
seem to have a gap in their usability logic.)
 
"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)."
 
If the app MUST NOT continue normal processing, how can it properly
"make unprocessed data
from the document (with intermingled character data and markup)
available to the application" [to support the correction of errors]
 
It seems to me (and it seems plainly stated to this effect in the
manual/instructions accompanying the parser I use) that once the
exception is thrown there is no guarantee what state the parser
will be in - and therefore it seems an unreliable point from which
a developer's code can start to correct the error in the markup.

Best regards

Steve
---
Stephen D Green



On 17 July 2011 10:20, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
Here are some excerpts from XML specification itself.

<quote>
error: A violation of the rules of this specification; results are
undefined. Unless otherwise specified, failure to observe a
prescription of this specification indicated by one of the keywords
MUST, REQUIRED, MUST NOT, SHALL and SHALL NOT is an error. Conforming
software MAY detect and report an error and MAY recover from it.

fatal errors: 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).

well-formedness constraint: Violations of well-formedness constraints
are fatal errors.
</quote>

Here are few examples of "errors" and "fatal errors" from the XML spec itself.

examples of "errors",

<quote>
1) This specification does not give meaning to any value of xml:space
other than "default" and "preserve". It is an error for other values
to be specified; the XML processor MAY report the error or MAY recover
by ignoring the attribute specification or by reporting the
(erroneous) value to the application. Applications may ignore or
reject erroneous values.
2) It is an error if an attribute value contains a reference to an
entity for which no declaration has been read.
</quote>

examples of "fatal errors",

<quote>
1. It is a fatal error for a TextDecl (i.e <?xml' VersionInfo?
EncodingDecl S? '?>) to occur other than at the beginning of an
external entity.
2. It is a fatal error if an XML entity is determined (via default,
encoding declaration, or higher-level protocol) to be in a certain
encoding but contains byte sequences that are not legal in that
encoding.
</quote>

I hope this is helpful.

On Sat, Jul 16, 2011 at 9:17 PM, Joe Fawcett <joefawcett@hotmail.com> wrote:
> Dear List Members
> I'm writing a short introduction to XML and would like to have a good
> example of each of the above that doesn't require too much background
> knowledge. So far I've covered the basics of a well-formed document,
> creating elements and attributes. I've shied away from the intricacies of
> DTDs as they are covered in a separate article. Namespaces are also to
> be covered later so any examples would preferably be unrelated to either of
> these two areas.
> According to the XML specification a processor may recover from an error
> that's not described as fatal although in my experience most parsers don't
> try to do this, would I be wrong here? - and if so what would an example be
> for something like Saxon or one of the netter known parsers?
> Thanks





--
Regards,
Mukul Gandhi

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS