W3C Technical Architecture Group (The TAG) is nowholding an election for a new member, and I'm running forit.

Let me introduce myself. My name is SergeyKonstantinov, and I'm working for Yandex (most recently asa Maps API R&D Head). Obviosuly, I'm not well-known atW3C as Yandex hasn't been a member for a full year yet.But this doesn't mean that we have little experience withstandards. Just the opposite - we have years of experiencein dealing Web Standards and maintaining our own APIs,which are de facto standards in our home markets. Weacquired some expertise in API lifecycle management thehard way, and we know very well that the rapid developmentof new standards always carries risks.

So ourprimary concern is the fresh new Web Standards whichemerged in the last few years. There are dozens of newstandards, and that's very good for developers as theyhave new possibilities; but it also means that inevitablythere will be the problems of growth: inconsistencies,controversies and architecture flaws.

The TAG'sstated mission is: "(1) to document and build consensusaround principles of Web architecture and to interpret andclarify these principles when necessary; (2) to resolveissues involving general Web architecture brought to theTAG; (3) to help coordinate cross-technology architecturedevelopments inside and outside W3C.". So that's why I'mhere, and that's exactly the thing I'd like to do. If theTAG needs reform to comply with its mission -- then, okay,call me the reformist.

Working on our own APIs westrictly keep to "use-case-centic" approach. It means thatwe understand the task not just as creating some methodsand formats, but building useful tools for the web mastersthat allow them to solve their users' problems. Everypiece of functionality must have a reason: who will useit? how? what problem does it solve? And, of course: is itclear, how to use it and what problem itsolves?

Regretfully, for Web Standards, thoughthese principles are generally accepted, theirimplementation leads to inconsistencies across thedifferent Working Groups, because every WG has its ownvision on Standards development. We have many standardswhich are pretty clean and functional, but make thedevelopers to write bad code, to make common mistakes oreven to abandon the idea of using the Standard in theirservices. The structure that should coordinate all the WGsto help WGs to elaborate the common approach is theTAG.

Let me say a risky thought: the beauty andthe cleanness and the perfection of the standard do notautomatically mean the ergonomics and the usefulness. Letme also say that the task of encouraging the developers touse the standard properly, of spreading good programmingtechniques and of making the standard work as it intendedto, is far more tricky thing than just to make it cleanand functional. I'm sure that our vast experience indealing with the webmasters will be of help for the TAGand for the Web in general.

I should also note,that from our distant view there is also a clearly visiblelack of W3C localization. Russian (Indian, Japanese,Chinese, etc) developers are greatly relying on localcontent and local developer societies, and the W3C isrelatively unknown here - nor the local demands are knownto W3C. I hope to bring some local expectations to the TAGand to popularize the Web Standards and W3C work to localcommunities in addition to the main work with standards.