Subject: status matrices and XSL (was Re: POW -- which locales Just Work?)
From: Paul Rohr (paul@abisource.com)
Date: Mon Mar 05 2001 - 15:10:52 CST
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.
bottom line
-----------
My hope is that you'll find it easy to do any XSL-specific work required
here. Would you be willing to do so?
If so, then it should be quite straightforward to do the remaining work of
replacing our existing outdated matrices with a easily-maintained XML/XSL
variant.
Thanks again,
Paul
This archive was generated by hypermail 2b25 : Tue Mar 06 2001 - 02:22:44 CST