[qmtest] RFE: result annotations

[Stefan Seefeld]

Mark Mitchell wrote:
> On Tue, 2003-09-23 at 23:09, Nathaniel Smith wrote:

>>Do we even know that annotations are, in general, proper XHTML?
>>We've documented them as being HTML (though they're not even properly
>>treated as that ATM; we don't handle character entities right at all),
>>and HTML in real life is rarely well-formed XML.  I'm worried that if
>>we start parsing it as XML, we'll start getting parse errors
>>who-knows-where...
> 
> 
> Right now, we assume they are HTML, not XHTML.
> 
> And, we do handle character entities correctly in results files; they
> are escaped.

yes, the current solution works, with a proper definition of 'works'.
But why can't we require the annotation author to use valid xml (i.e.
balancing start and end tags, properly escaping of special characters),
and through this gain a lot of power for the postprocessing of these
data ? Just using some non-validated form of html doesn't gain anything
but the hope that it might render nicely in a browser even without the
efford to adhere to a stricter grammar.

I don't think the proposed change would cause any trouble for backward
compatibility. I'm talking about generating well-formed xml inside
qmtest.
The parsing of these data (wherever that might be necessary inside
qmtest) could be more relax...

> If the HTML is invalid, it will be stored correctly in the results
> files, but not displayed correctly in the GUI.  (I'm not sure how to
> correctly display invalid HTML, but we make no attempt to discern
> validity; we just dump it into the web page.)

I don't understand your argument. Are you arguing that qmtest should
be agnostic to the content of annotations, and just try to do the
best it can to still render it nicely (in its web frontend) ?

If you are concerned about the burden for users to convert their
annnotations to valid xml, why not just provide a convenience function
that escapes the string or wraps it in a CDATA section or somesuch.
That's ugly enough (and should be discouraged), but it's all that is
needed for backward compatibility.

I'm really just trying to enhance the output data structure to make
automatic postprocessing more efficient.

Regards,
		Stefan