Subject: Re: status matrices and XSL (was Re: POW -- which locales Just Work?)
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Thu Mar 08 2001 - 10:00:06 CST
On 05 Mar 2001 13:10:52 -0800, Paul Rohr wrote:
> Karl,
>
> I'm getting very excited about the XSL work you're doing here. One of the
> biggest problems we had with these status matrices was that it was too hard
> to maintain them. The approach you're taking seems much, much better.
>
> For each of the three documents (feature, UI, and locale), I think we're
> getting very close to a setup where:
>
> - people maintain the simple XML format,
> - Sam adds a script to do the static XSL transformation, and
> - we publish the current results as HTML.
>
> Since the other matrixes are a bit more complex, I've been thinking that we
> could simplify and streamline the whole process as follows:
>
> 1. File *all* identified issues as either bugs in Bugzilla, or POWs
> --------------------------------------------------------------------
> Suggested syntax for your XML file format:
>
> <bug id="1046"/>
> <pow url="..."/> (ie, the relevant mailing list archive URL)
>
> I'm impressed that you can replicate the footnote style of the original
> matrices, but the more I think about it, the more convinced I am that my
> original decision to do footnotes was lazy and misguided. (Sorry for
> wasting your time implementing them.)
>
> While it's *very* helpful to have quick overview pages like this, that's
> really all these documents should do. All descriptive information about the
> details of various issues belongs in a database where anyone can update it,
> instead of leaving it "locked up" as static text inside this document.
>
> In short, I think we should follow Eazel's precedent and track *all*
> potential work items in Bugzilla. Plus which, it makes this page a lot
> easier to scan. :-)
>
> 2. Add support for all of Bob's original categories
> ----------------------------------------------------
> One of the nice features of Bob's information design for the two original
> matrixes was that he picked seven canonical colors to express the following
> concepts:
>
> <pre>
> cell
> color semantics value visible contents
> ----- --------- ----- ----------------
> #00FF00 Just Works yes "yes" | cell contents
> #00BB00 not for 1.0 later "v2.0" | <pow>
> YELLOW partially done partial <bug>+ | <pow>
> ORANGE unusable buggy <bug>+ | <pow>
> RED not implemented no "no"
> #BB66FF not tested unknown "??"
> #E0E0E0 not applicable n/a "n/a"
> </pre>
>
> Note that for most of these cells, the only thing we'd need to output is a
> static string, so long as the cell has no contents.
>
> In some cases, such as the feature matrix, we'd want explicit text (the i,e
> stuff) to override the default "yes" string. In other cases, we'll need to
> link in one or more bug #s, or perhaps a specific POW, as listed in the
> underlying XML file. However, in all cases, these can be done briefly
> inline, instead of having to link out to a footnote.
>
> How hard would it be to modify your existing XSL to do this?
>
> 3. Divide into sections
> ------------------------
> Fortunately, the locale matrix is pretty simple, because everything winds up
> in a single table. However, we've divided the other two matrices into
> sections to make them easier to read.
>
> >From skimming your XSL template, I'm assuming that inserting the chunks of
> explanatory text between tables is quite easy. (Basically, it's a cut &
> paste job from the current HTML file to the appropriate spot in the XSL
> file, no?)
>
> However, I'm not sure how much work it'd be to recognize which portions of
> the underlying XML file go into which section. For example, your current
> XML hierarchy goes matrix - header - row - cell. Since we're using the same
> headers across all sections, how hard would it be to introduce a section
> level between the header and the rows?
>
> 4. What XSL tool do you recommend?
> -----------------------------------
> Finally, what tool would you recommend that Sam use on our server to
> automatically run the XSL transformations? Once that's in place, it'll be a
> *lot* easier to recruit folks to do the testing required to update various
> cells.
I would recommend xalan (from http://xml.apache.org/). With the package
that contains the lib, there are some test programs, and one of them
performs a XSLT from the command line (you should specifie the .xml file
& the .xsl file, and it will output the transformated file). From the
doc:
TestXSLT -in xmlSource -xsl stylesheet -out outputfile
I've only tested the java version of the lib, but it seems that the C++
version works pretty much in the same fashion...
Hope that helps
Cheers,
-- Joaquín Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Thu Mar 08 2001 - 10:02:10 CST