xml-dev - Re: Realistic proposals to the W3C?

[Ronald Bourret <rpbourret@rpbourret.com>]

A good list of questions -- thanks.

> Mike.Champion@SoftwareAG-USA.com wrote:
> PROPOSALS, RECOMMENDATIONS, AND STANDARDS?
> 
> What do you folks WANT a "W3C Recommendation" to signify?

A stable technology that meets the (publicly-reviewed) requirements of
the WG.

> How much
> implementation experience from OUTSIDE a working group should be
> necessary to enshrine something as a Recommendation?

As a general rule, any implementation, whether inside or outside the WG,
should turn up technical problems, so my worries are less about
inside/outside that about any implementations. However, I think at least
some (two?) implementations from outside the WG are necessary to ensure
that any internal implementations aren't based on folklore known to the
WG but not the general public.

> Should the W3C
> encourage Recommendations to be modular components that can be
> assembled into anything from minimal subsets to monolithic
> monstrosities, or should the current "one size fits all" objective be
> maintained?

Case by case. I think if you can show good use cases for a minimal
subset, then those should be allowable. But there is a real judgement
call here in that you don't want so many options that implementations
can't play together due to fragmentation.

> Should Recommendations be treated as "standards," should
> there be a something like a "Strong Recommendation" that has survived
> the test of time and the market, should the W3C refer well-established
> Recommendations to the ISO, or what?

In practice, Recommendations are often treated as standards. I think the
idea that something can't move from CR to Rec without implementations is
a good one.

> OPENNESS
> 
> Given that there's no way the W3C is going to make the detailed votes
> on specific proposals available to the public (sorry, it ain't gonna
> happen, so don't bother flaming me), what could it do to maximize the
> benefits of "sunshine" without drying up the information flow? 

I can't speak for others here, but I sometimes feel like contributing to
the public mailing lists is like walking past somebody in the hallway,
saying, "Hi", and having them just keep walking. After a while, you
begin to wonder if they know you exist.

As Matthew Gertner pointed out, there is a real PR issue here. Even if
the WG addresses all points on the public mailing list, the people who
submit comments aren't likely to feel like their comments are worthwhile
without an actual reply -- just seeing that your change made it into the
next draft isn't enough, as you have no idea if you've had any effect or
the change came from someone else.

Although it's not always the case, I'd often be satisfied with a list of
quick, point-by-point answers:

"Good point. We'll take it up."
"We've done it -- it'll be in the next draft."
"Sorry, we've considered that and voted against it -- here's why..."

Ideally, I'd like to be involved in a technical discussion of the points
I raise, but if that isn't going to happen, I'd at least like some
recognition that I'm not wasting my time.

> Make
> Interest Group mailing lists open to qualified people who agree to
> respect certain guidelines (such as not publicly revealing who
> advocates what)?

That would make me very happy. I'm less worried about total openness
than about being able to follow and, at least occasionally, be part of
the process. As Matthew said, I also haven't heard any good reasons that
the technical points can't be discussed with people outside the W3C.

> Eliminate Interest Groups and encouraging all
> technical discussion to occur on the public mailing lists and all
> member-confidential stuff to remain on the WG mailing lists?

If this wouldn't dry up contributions, then yes. If, on the other hand,
it isn't going to happend due to member companies viewing it as too much
cannon fodder for sensational journalism, then the above solution is
fine with me. After all, I think what a lot of people are asking for
here is to be a meaningful part of the solution.

> Farm out
> the public "brainstorming" of specs to OASIS TC's and produce SAX-like
> "sense of the community" proposals, and only setup Working Groups when
> the time comes for the heavy hitters to go into the smoke-filled rooms
> to sort out who can implement what when?

Farming out brainstorming is fine, but no WG is ever going to get all
the "heavy hitters" on board. Opening up technical discussions with some
form of non-disclosure as a condition of membership would definitely be
in the W3C's best interests.

> CLARITY OF SPECS
> 
> What should the W3C as an organization do to encourage clearer specs?
> Mandate a page limit?  Demand a relatively non-technical but
> "normative" Tutorial/Background paper to accompany all specs (at least
> at the Recommendation level)? Insist on an open source reference
> implementation? Mandate some other formal language description?

As a general rule, I don't think you can write many rules about how to
write good specs, so I think that most of what can be done here is in:

1) Having the W3C state that part of any WG's mission is education of
the public about that WG's topic. Given the W3C's attempts to stay ahead
of the technology curve, rather than standardizing existing technology,
this strikes me as a fundamental part of their mission.

2) Tutorial/Background papers are a good way to do this, as are less
formal writing in the specs, annotated specs, etc. I think it it's
reasonable to let each WG work this out on their own, based on the
writing styles of the spec editors.

What is important is that the WG doesn't think it's job is done if their
work is only understandable to them and a handful of well-educated
outsiders, no matter how well it is written, precise, or complete it is.

-- 
Ronald Bourret
Programming, Writing, and Training
XML, Databases, and Schemas
http://www.rpbourret.com