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

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



[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