Re: [xml-dev] Error and Fatal Error

[Stephen D Green <stephengreenubl@gmail.com>]

Mmm. But in this case the 'supplier' is the app I'm

writing - and the user of that app who is inputting

data into one of the web pages which my app then

tries to take and send to an XML parser. Yes, I

can instead have the app send it first to some other

parser but, with something like .NET, I and my fellow

web developers and managers and employers don't

expect to have to write a parser but expect there to

be one available as part of the framework we use. 

I think we need a parser which understands the

slightly erroneous XML and can find any errors in it:

In short we need a parser which has an API which

can allow the web developer (in this case with .NET)

to repair XML.

 

I would imagine a MicroXML parser for .NET could

do this for any XML which sticks to the limits of that

XML profile but really it needs to be able to handle

any kind of XML, like the existing XML parser can

(pretty much I think). I still maintain the XML spec

of any future XML revision is the starting point for

the production of such parsers (perhaps including

MicroXML, or similar profile of XML, parsers). This

is perhaps the first step to plugging this gap but why

should the spec writers do this? 'He who pays the

piper calls the tune' but if nobody is going to pay the

spec writers for the maintenance of the XML specs

then why should they repair or fill any gaps like this? 

----

Stephen D Green

On 16 July 2011 18:35, Andrew Welch <andrew.j.welch@gmail.com> wrote:

> I hunted around the .Net framework hoping to find such
> a parser which allowed me to repair the XML but I couldn't
> find one.

The usual approach here is to reject the input as 'not xml' and then
go through some feedback loop with the supplier to correct their
non-xml.  The next stage (if you have to) is to accept the feed with
its faults, and insert some preprocessor to tidy up the known issues.

One preprocessor could be to convert all bytes over 255 to character
refs, to work around encoding issues.

--
Andrew Welch
http://andrewjwelch.com