From: Rob Stewart (stewart_at_[hidden])
Date: 2002-07-10 12:45:38
From: "William E. Kempf" <williamkempf_at_[hidden]>
> From: "Rob Stewart" <stewart_at_[hidden]>
> > Boost isn't likely to post XML with a reference to an external XSLT
> > expecting the browser to perform the transformation.
> I don't know... this is a simple solution. There's pros and cons, and
> you're probably right that we'd be better off providing a fully transformed
> HTML file using an XSLT transformation utility, but the pros and cons should
> at least be discussed.
> * Simple implementation.
> * Doesn't require "lengthening the tool chain".
> * Release process isn't complicated by another set of scripts needed to
> transform the XML.
If you choose to create HTML reports to post at the web site, then this must be
done. I think we're saying about the same thing. I just figured you'd want it
to happen automatically, at least for the web site.
> * Boost users can produce their own reports using only tools they're
> likely to have already (C++ compiler, Jam and a "modern" web browser).
Sure. I hadn't considered that aspect of generating the results.
> * If the user doesn't have a "modern" browser he can't view the transformed
The other problem is which browser you target with the resulting HTML.
> > Instead, I expect that
> > Boost will generate the HTML as a normal step in the regression test
> No, I'd expect the HTML generation to be a seperate step. This way users
> with out an XSLT transform utility can still run the regression tests. Even
> if they don't have a) a "modern" browser or b) an XSLT transform utility,
> they could still read the resultant XML file. Also, this makes it so that
> Boost doesn't have to pick an XSLT transform tool that all users (who want
> to run regression tests) must agree to.
That's fine. I wasn't thinking at that granularity.
> > Therefore, there doesn't seem to be a compelling reason to use XSLT over a
> > scripting language with SAX2.
> The compelling reason to me is that we can keep the dependencies on tools to
> a minimum, both for the Boost release process and the Boost user base.
> Using XML and XSLT gives maximum flexibility with minimum requirements on
If the person writing the transformation is more comfortable with Python and
SAX2 (I'm assuming Python support, here), then I don't think we should impose
XSLT. If that person must learn new stuff either way, then I, too, would favor
> Generating XML is trivial... it's format is human readable, similar to HTML,
It can get painful to read if care isn't taken to include appropriate newlines,
but otherwise you're correct.
> and easily rendered using simple iostream output. Once a structure is
I'd encapsulate that functionality in some RAII classes that insert opening and
closing elements automatically because it will make generating well-formed XML
easier. Such classes would need to allow inserting attributes, too, so you'd
need to pass them to the ctor -- at least for a simple implementation. There's
probably something already available to make that easy anyway.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk