A suggestion for TAG output

During our call today we discussed the form that the output
from the TAG's work might take.  I went and reviewed the charter
and have some thoughts on this.  The charter talks about various
activities involving interpreting, co-ordinating, and documenting
architectural issues.  It also talks about producing recommendation-
track "Architectural Recommendatios" per the regular W3C process.

Let's consider the recent request for input from the Protcol WG
on the subject of media types.  This seems like a reasonable
example of the kind of problem that the TAG exists to solve.  So
let's assume that we take up this question and make some 
architectural findings as a group.  Then: do we want to
go through the overhead of the full Recommendation process for
what amounts to answers to three straightforward questions?

At the same time, it's been suggested in our discussions that 
we generate an overarching "Web Architecture" document in outline
form and work our way through filling it in.  This sounds good,
but I'm dubious about the practicality of trying, as a group,
to figure out the right outline and fill in the important bits
first.  Seems like a very big job.

Finally, it seems to me that the areas where the TAG's
work is most important is precisely those where architectural
issues are causing problems out there in the lives of the 
Working Groups.  So we ought to be cheerful about being guided
by the requests for help that come to us, whether from Working
Groups or from other intervenors who spot architectural problem
symptoms in current WDs.

Let me suggest a strawman approach to organizing our output
that might address several of these concerns in parallel.

The TAG would from time to time issue Findings in response to
architectural issues causing pain in the field.  Taking the
recent XML Protocol request as an example, we might issue a
finding that WGs who invent XML languages are required to
give them a namespace name and register a media type, unless
there are powerful specific reasons not to.  [Not presupposing
the TAG's discussion of this, just doing a thought experiment.]
Such a finding would be a short and fairly self-contained
architectural policy statement.

At the same time, we could invest the work in building an 
architectural outline into which the findings could be slotted.
However, the findings would be the official "normative" output of
the TAG, and if someone wanted to organize them in a different
outline that would be OK.

So, this seems to allow the TAG to act reasonably quickly,
to address the architectural problems where they're causing 
pain, and to fill in a larger overarching document.

There's another problem here and I don't yet see the good
solution.  At what point does TAG work need to go on the
W3C Recommendation path?  It's hard to see this as cost-
effective or reasonable for the XML Protocol questions, as
an example.  The W3C membership created the TAG to handle
this work and presumably has given us some kind of a 
mandate to make decisions.  Furthermore, since we work
in public, so everyone who cares in principle gets a 
chance to shout at us and keep us from doing something 
stupid.

But then, can our output have any normative force without 
the weight of the Recommendation process?  For example, suppose 
we issue a finding as outlined above, and then a couple of dozen 
W3C members or a couple of thousand Slashdot readers claim it's 
nuts to require the creation of media types for new XML languages; 
the Recommendation track is designed to work precisely through that 
kind of situation.

Could we imagine batching up a year's worth of TAG findings
each year and taking it down the Recommendation path?  

Or does someone else have a better idea?  I'd much rather argue
about media types and namespaces, but we do need to invest some
time in deciding what to do with the results of our work. -Tim

Received on Monday, 14 January 2002 14:49:59 UTC