[boost] Re: Regression test / compiler status progress

From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2002-07-11 00:16:56

As someone who's actually done a fair bit with XSLT, I thought I'd throw
another voice into the fray...

"William E. Kempf" <williamkempf_at_[hidden]> wrote in message
news:OE3033HFnwpGR881Np700008b40_at_hotmail.com...
>
> I don't think we're talking the same thing.  An XML file can explicitly
> refer to an XSLT file and "modern" browsers will do the transform on the
> fly.  No need to produce an (static) HTML file at all.  Open the XML file
in
> the browser, it sees the link to the XSLT and loads it as well and does
the
> transform on the fly.  It's the pros and cons with this that I was
referring
> to.

One "problem" with automatic XSLT transforms on the browser is that you can
expect that 85% of users will view the site with IE, and only IE6, which
installs MSXML3 by default, will correctly display XML using a standard XSLT
stylesheet.  Earlier versions install MSXML2, which supports only a
pre-stanard dialect of XSLT.

>
> My suggestion is to provide the best of both worlds.  Produce the static
> HTML which will be linked to on the Boost web site (so even older browsers
> can view it), but link the XML to the XSLT for use by Boost users who have
> "modern" web browsers and would want to produce their own regression test
> reports with out the need for running an XSLT tool to produce static HTML.

I think this is the way to go, absolutely.  Having a compiled C++ program
emitting HTML is, in a nutshell, silly.  Emit XML, run it through a static
XSLT convertor to produce HTML, and post the HTML, the XML and the XSLT to
the web site (as, for example, is done with nearly all W3C documents now).

>
> You don't "impose XSLT" on anyone.  The transform provided by Boost should
> be via XSLT for the reasons I've outlined, but this in no way limits
someone
> from writing their own transform using what ever tools/languages they wish
> to.  That's the power of XML.
>
> The PROS for using XSLT:
>
> * It's a standard.
> * Modern web browsers can do the transforms on the fly, eliminating the
need
> for many (most?  all?) users from having to use a tool they may not have
> installed.
> * Since it's a standard there are numerous tools that can do static
> transforms, so Boost doesn't have to pick a "Boost sanctioned transform
> tool" like we had to do for build scripts (though we've kept the
> dependencies here to a minimum as well).
> * Once you've learned XSLT it's trivial to modify an existing XSL file for
> customized output.
> * Even with out understanding some XSLT commands you can often still
> customize an XSL file to fit your needs, since the majority of the file is
> going to be pass through HTML any way.

I'll second all of that!  It's true, XSLT does require that you turn your
brain sideways at first (unless you're a big functional programmer already),
but it only take a few hours to master enough XSLT to do everything that the
Boost status page would require.

>
> The big CON with SAX or other approaches is that they tie you into a tool.
> Users can't produce their own reports with out either using a "Boost
> sanctioned" tool, or writing their own transform.  In other words, the
fact
> that modern browsers can view transformed XML files directly means that
it's
> less likely a user will need any tools at all, and if he does, he has a
> large choice of tools to use.

Amen.

>
> That's actually a reason to produce the XML by hand.  Most DOM engines
> produce terrible output, for instance.
>

Actually, I'd favor emitting the XML in the most straightforward way, making
absolutely no attempt to have it formatted nicely.  If you want nicely
formatted XML, you can easily write an XSLT stylesheet to "pretty-print" the
XML.  Keep the requirements on the C++ program as simple as possible.

-cd