[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Error and Fatal Error
- From: Chris Burdess <dog@bluezoo.org>
- To: stephengreenubl@gmail.com
- Date: Mon, 18 Jul 2011 14:47:50 +0100
Stephen D Green wrote:
> I shouldn't really rise to this one, but here goes anyway:
>
> 1) I wasn't thinking anything except XML would be parsed with an XML parser
>
> 2) some say if XML has illegal characters it is not XML but I say - then why does
> the spec talk about errors in the XML (if the XML had errors, then by that reasoning
> it wouldn't be XML, ...)
According to the spec (section 1.2), XML may contain errors and still be well-formed (i.e. XML). The result of processing a document with errors is not defined, but the processor may recover and continue processing. *However*, a processor shall not recover from a fatal error. Illegal sequences of characters in the input constitute a fatal error, meaning that the input is not well-formed and hence not XML.
> 3) rational people have obviously had it in mind in writing the spec that XML can
> have errors which the parser would pick up and help them to correct - and that
> process has requirements for which I think the spec doesn't completely cater
The only reference that the spec makes to anything like this is (again section 1.2): "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."
This doesn't say anything about the processor "helping to correct" errors. All it says is that the processor is permitted to pass the not-well-formed input to the application so that the application has the opportunity to see what needs correcting.
> 4) I don't at all buy the argument that a few characters needing escaping mean
> some XML isn't actually XML and therefore isn't covered by the spec or the
> requirements for the XML parser
It's not an opinion. The XML format is fully described in the spec: if your input does not match the format, it's not XML.
> 5) some text is best parsed by an XML parser because it is within the scope of
> the spec if it is XML (even if it has errors) - because there is some text is
> to all intents and purposes XML (even with the errors)
See above: if it is XML containing recoverable errors then an XML processor is probably OK to parse it with, because most XML parsers do reasonably sane things in the presence of recoverable errors. If it contains fatal errors then it is not XML and an XML processor will correctly reject it.
> 6) I've had enough of trying to prove what to so many is blindingly obvious
Where exactly are these multitudes? In this debate so far nobody else has shared your opinion.
--
Chris Burdess
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]