Issue? Supporting documentation for Issue resolution

We skipped over an issue today that pertains to how the TAG communicates
findings.  I think that TimBL was suggesting that we provide a context
document to provide a coherent mechanism for relating issues (resolved and
unresolved).  I agree with TimBL on this.  Indeed, this issue was the first
issue that I raised [1].  Further, TimBL suggested a rational approach for
proceeding, that is a table of contents that categorizes issues.  As issues
are resolved, the text is then expanded upon.

I see this as being a reasonable process for creating an architecture
document.  We do not have the time nor mandate to create an arch document
top-down, so this bottom's up approach is reasonable.

I'd like to raise this is an issue, ie Issue[archdoc-6]: Clarify the process
for producing documentation, and what forms of documentation are produced.

I also suggest that this architecture document would be the item that is
passed into the Recommendation Track, assuming that each individual issue
resolution isn't passed into the Rec track.  I think we should try for a
version of the arch document every 6 months at the least.  This would show
progress and allow for timely reviews.

Cheers,
Dave
[1] http://lists.w3.org/Archives/Public/www-tag/2001Dec/0022.html