std.xml2 (collecting features)

[Brad Roberts via Digitalmars-d]

An old friend of mine who was intimate with the microsoft xml parsers 
was fond of saying, particularly with respect to xml parsers, that if 
you hadn't finished implementing and testing error handling and negative 
tests (ie, malformed documents) that your positive benchmarks were 
fairly meaningless.  A whole lot of work goes into that 'second half' of 
things that can quickly cost performance.

I didn't dive or don't recall specific details as this was years ago.

The (over-)generalization from there is an old adage: it's easy to write 
an incorrect program.

On 5/5/2015 11:33 PM, Jacob Carlborg via Digitalmars-d wrote:
> On 2015-05-05 16:04, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
> <ola.fosheim.grostad+dlang at gmail.com>" wrote:
>
>> In my opinion it is rather difficult to build a good API without also
>> using the API in an application in parallel. So it would be a good
>> strategy to build a specific DOM along with writing the XML
>> infrastructure, like SVG/HTML.
>
> Agree.
>
>> Also, some parsers, like RapidXML only support a subset of XML. So they
>> cannot be used for comparisons.
>
> The Tango parser has some limitation as well. In some places it
> sacrificed correctness for speed. There's a comment claiming the parser
> might read past the input if it's not well formed.
>