Boost logo

Boost :

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
> stylesheet,
> > 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.

No argument.

> * 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
> report.

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
> build.

> 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
> tools.

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, gregod at, cpdaniel at, john at