Re: [boost] Regression test / compiler status progress

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-07-11 09:32:52

        <D1CF0387F1A4D51182B600D0B7A7A95F0714EC_at_[hidden]><200207101451.g6AEp8b20867_at_[hidden]><OE59hAUTfomolIiCSF30000878d_at_[hidden]>
        <200207101745.g6AHjcu21827_at_[hidden]>
        <OE3033HFnwpGR881Np700008b40_at_[hidden]>
X-BeenThere: boost_at_[hidden]
X-Mailman-Version: 2.1b1
Precedence: bulk
Reply-To: boost_at_[hidden]
List-Help: <mailto:boost-request_at_[hidden]?subject=help>
List-Post: <mailto:boost_at_[hidden]>
List-Subscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
        <mailto:boost-request_at_[hidden]?subject=subscribe>
List-Id: Boost mailing list <boost.lists.boost.org>
List-Unsubscribe: <http://lists.boost.org/mailman/listinfo.cgi/boost>,
        <mailto:boost-request_at_[hidden]?subject=unsubscribe>
List-Archive: http://lists.boost.org/MailArchives/boost/
X-List-Received-Date: Thu, 11 Jul 2002 14:28:32 -0000

From: "William E. Kempf" <williamkempf_at_[hidden]>
> 
> From: "Rob Stewart" <stewart_at_[hidden]>
> 
> > From: "William E. Kempf" <williamkempf_at_[hidden]>
> > >
> > > From: "Rob Stewart" <stewart_at_[hidden]>
> >
> > 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.

I understand this full well and have done it on many occasions.  My point was
that not all clients have browsers that do that so you'll probably want to
generate HTML to post on the web site. Given that, generating those reports will
be part of the release process and my comments apply.

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

That's fine.  I was just pointing out that there are incompatibilities and that
if the pages were to include any DHTML or scripting, there would be problems.
HTML 4 is a fine standard to apply.  Nevertheless, you have to specify a
target. 

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

That was my point.

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

That's effectively what I've been saying once you pointed out the benefit to
some clients of using just XML output.  Again, I'd say we're in violent
agreement.

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

You just imposed XSLT on the person that will be in charge of generating HTML
for the Boost site (since you volunteered below, that's not much of a problem,
eh?).  The point is simple: we want to generate XML and HTML from it.  How that
is done is up to the person charged with producing the HTML.  XSLT would be a
good choice, but if that person is more comfortable with a scripting language
plus SAX2, then its reasonable to let them do it that way.  Obviously, not using
XSLT means that you simply cannot allow for the automatic browser-based
transformation and that's a significant drawback. 

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

I was mentioning it so Beman, or whomever, would have that idea in mind.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;