Re: [boost] Regression test / compiler status progress

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-07-10 16:00:52

----- Original Message -----
From: "Rob Stewart" <stewart_at_[hidden]>
To: <boost_at_[hidden]>
Cc: <boost_at_[hidden]>
Sent: Wednesday, July 10, 2002 12:45 PM
Subject: Re: [boost] Regression test / compiler status progress

> 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.
>
> Reasonable.
>
> > PROS
>
> > * 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.

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.

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

That's mostly a non-issue.  If you stick to standard HTML 4, the results
will be decent on all modern web browsers.  The reports here aren't going to
be any different then the documentation pages provided by Boost libraries in
this respect.  The only issue is whether or not a broswer is "modern" enough
to support XML and XSLT.  If it's not, you need to do the transform either
statically or on the server side, and of these only static transforms would
be usable for Boost.

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.

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

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.

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.

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

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

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

May or may not be overkill in this particular case.  We're not developing a
library for XML output (though that might be a useful thing to have) but
simply producing one specific, and fairly simple, XML file.  In any event,
that's an implementation detail that know one but Beman will care about.  I
was only trying to point out that producing XML would be at _least_ as easy
as producing HTML, and probably easier.

Beman, if you'd like I could volunteer to do some of this for you.  I could
produce the XSLT file, and if it's easier I could even modify the
executables output to be XML after you get a working HTML version finalized.
What ever is easier/best for you, and assuming you agree that XML is a
better output choice here.

Bill Kempf