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

[Jonathan.Robie@SoftwareAG-USA.com]

Title: RE: Realistic proposals to the W3C?

Mike.Champion@SoftwareAG-USA.com wrote:

> MISSION
>
> What does "leading the web to its full potential" mean to YOU? 
> Charging forward toward the Semantic Web, cleaning up the loose
> ends left behind by the Syntactic Web (?) or what?

1. Solidifying the existing technologies in the Syntactic Web - filling in the gaps, making things work more smoothly.

2. Playing around with new technologies that may or may not work out. Go ahead and define the Semantic Web more fully, creating the interfaces, serialization formats, query protocols, etc., and see if it catches fire. If not, try something else. Move into XML Protocol. Try whatever seems promising. Don't worry if several attempts at defining new things don't work out, as long as you have a few interesting ideas that pan out every year.

3. Make sure we take Internationalization and Accessibility into account so that the Web is not just for the sighted English speaking world.

4. Embrace non-W3C standards and be careful not to break their usability together with the XML standards (e.g. SAX)

I think the W3C is pretty much on track as far as this goes.

> PROPOSALS, RECOMMENDATIONS, AND STANDARDS?
>
> What do you folks WANT a "W3C Recommendation" to
> signify?  How much implementation experience from
> OUTSIDE a working group should be necessary to
> enshrine something as a Recommendation? 

Is there one rule that works for all possible technologies? I would want a *lot* more review for something like Schema or Query than for the DOM.

Right now each Working Group can make its own call on this, within certain guidelines. I suspect that's probably OK. I do wish that certain groups would get a lot more external feedback and have a lot more confidence that a solution is solidly defined before going to REC status.

> 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?

That's easy. I'm happy when I understand a 30 page spec well enough to vote intelligently on it, even if it is well written. When it gets up to 300 pages of unreadable prose, my voting pattern is equally unintelligable. A spec should never be so complex that members of the Working Group that defines it have a hard time keeping grasp of the details. Small and modular is important.

> Should Recommendations be treated as "standards," should
> there be a something like a "Strong Recommendation"

That's a tough one, and it isn't really up to the W3C. The marketplace makes these decisions. It has decided to give more authority to W3C specifications than the W3C claims for them. To the extent that this buys interoperability, that's good.

But when do we clean up our old mistakes? In theory, I think the W3C wants to be a research lab that creates technologies that are used in the marketplace, and leave real standardization to standards bodies. (I should probably ask a W3C employee about that just to be sure ;-> )

It would be nice to get a few years experience with each specification, wipe the slate, and write a cleaner version of it as a Real Live Standard. That would break interoperability with a few year's worth of data, and I'm not sure that can really work. So the W3C's "non-standards" do become entrenched to the point that they are hard to replace.

So what do we do? We have to try out new technologies and get them to market fairly rapidly, and we just can't get everything right the first time around. I'm not sure if it helps for ISO or some other body to create the slightly incompatible standard - the legacy issue remains the same.

> OPENNESS
>
> There are three types of mailing lists associated with
> a W3C working group: public, "interest group", and
> "working group".  The public lists are open to anyone
> and are used (as near as I can see) mostly to solicit
> feedback from the public.  Some working groups (the DOM
> anyway) try hard to quickly answer/explain/acknowledge
> the posts on the public mailing lists, others respond
> mainly in the "disposition of public comments"

An active public mailing list is a Good Thing.

It is also a Time Consuming Thing, as we both well know. To me, this often boils down to questions of who has how much time for what. Do the editors for a given spec think it is worth spending that amount of time on a public list or not? That's the decision that each group of editors must make, and I think it can be a case-by-case decision.

Certainly, it is very helpful to post regular Working Drafts and solicit feedback at well defined intervals, whether or not the Working Group has time to do this throughout development.

> 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?

Excuse me while I put on my flame-proof suit, but...

I think the current process works pretty well. During the development of Working Drafts, the public lists (dare I say it?) are simply not as time efficient as the internal lists, because the public is not devoting 20-50% of their time to understanding a particular technology, they are not in touch with the oral folklore that surrounds any development project and does not appear in writing, and our internal documents are often insufficient to help people offer informed feedback - until they are mature enough to be issued as Working Drafts for public comment. Given that the Working Groups I am currently involved in are both over 50 people, with no more than 2 per company, we have plenty of industry experience coming in, and I am also in direct contact with other researchers at many of these companies. I am *overwhelmed* by the amount of very high quality information that is coming in from many extremely different perspectives.

Working Groups should be - and are - encouraged to publish public working drafts for review on a regular basis, and to solicit feedback at that time. This feedback is only useful if the specs are readable.

> CLARITY OF SPECS
>
> What should the W3C as an organization do to encourage clearer specs?

If I wanted to be radical, I would suggest a QA team within the W3C. To pass QA, a spec has to be readable, and unambiguous for the questions that the QA team investigates. That team might actively solicit feedback from the public. Until the specification passes QA, it should not be allowed to proceed to Candidate Recommendation status. The QA team should consider themselves the ombudsman (ombudskvilla?) for the development community.

Jonathan