W3C будет вести себя так, как сам напишет

Заключительная статья рубрики посвящена рассмотрению последних изменений в
документе, регламентирующем деятельность W3C и разработку спецификаций
консорциума. Наши постоянные читатели, разумеется, помнят, что мы уже подробно
останавливались на этом документе.
Эта статья в определенной степени является продолжением поднятой год назад
темы. Однако, ее принципиальное отличие от большинства публиковавшихся ранее
статей заключается в том, что она явилась результатом интерактивной беседы с
одним из наших читателей Александром Савенковым. Александр занимается проектом
xmlhack.ru, и эта статья одновременно
публикуется и на xmlhack.ru. Надеемся, что выбранная нами форма подачи
материала не разочарует читателя. Думаем, что эту статью можно рассматривать
как небольшой сюрприз к юбилейному тридцатому номеру нашего Журнала.

Предисловие

Мы живём в период бурного развития информационных технологий, и особое место в этом процессе занимается расширяемый язык разметки XML (Extensible Markup Language). Уникальные возможности и свойства этого языка и, как следствие, его огромная популярность явились одной из причин образования целого ряда международных и отечественных организаций, занимающихся разработкой различных спецификаций на основе XML, предназначенных для решения широчайшего спектра задач.

Вряд ли кто-нибудь станет оспаривать, что особое место среди этих органов стандартизации занимает международный консорциум W3C, поскольку именно эта организация является автором многих базовых XML-стандартов и самого XML.

В этой статье речь пойдет не о стандартах, которые публикует W3C, а о правилах которыми он при этом руководствуется. Будет представлен обзор последних изменений в документе, регламентирующем деятельность W3C, и особенно исправлений в разделе, посвященном процессу разработки спецификаций W3C.

Однако, прежде чем перейти к рассмотрению самих изменений, будет нелишним сказать несколько слов об упомянутом выше документе. Процесс разработки рекомендаций W3C (W3C Recommendation Track Process) — это часть обширного документа, в котором описывается порядок работы W3C (W3C Process Document). Впервые этот регламент был опубликован в мае 1998 года, и тех пор вышло десять его версий. Полный перечень изменений, внесенных в текст данного документа, приведен на сайте W3C.

Мы затронем самые последние изменения в документе, а именно: редакции от 18 июня 2003 года и 5 февраля 2004 года. Было решено остановиться на этих изменениях, поскольку, во-первых, более ранний вариант документа (от 19 июля 2001 года) уже освещался в электронных информационных средствах, во-вторых, потому что эти изменения появились спустя довольно значительных срок после публикации версии от 19 июля 2001 года. Вместе с тем, необходимо отметить, что последняя модификация документа (от 5 февраля 2004 года), не столько существенна как предыдущая, однако, на наш взгляд, и она заслуживает внимания.

Статья оформлена в виде беседы: мы решили, что читателю, возможно, может наскучить читать только одно перечисление изменений в рассматриваемом документе.

При подготовке статьи мы не смогли избежать соблазна, и, воспользовавшись теми возможностями, которые нам предлагает интернет, провели интерактивную встречу. Предлагаем вашему вниманию некоторые наиболее интересные, на наш взгляд, отрывки из нашей беседы.

Обсуждение последних изменений

Александр Кудинов

Добрый день, Александр!

Александр Савенков

Добрый день!

А. К.

Ну, что же, приступим к обсуждению?

А. С.

Пожалуй.

Накануне я долго изучал текст старого и предпоследнего документов: должен сказать, что чем глубже я рассматривал текст, тем он больше мне нравился. Мне показалось, что косметические правки плавно перешли в качественные изменения, что благоприятно отразилось на читабельности. Тем более, изменения, произведённые в предпоследней редакции, давно уже назревали.

А. К.

Не могу с вами не согласиться. Единственное, что мне больше нравилось в предыдущей версии документа, — это оформление: например, наличие подразделов «Требования к документу» (Entrance Criteria) и «Проводимая работа» (Ongoing Work) — всё это, как мне кажется, предполагало более удобную структуру документа. Но в целом подача материала в новой версии стала гораздо более содержательной. Хотелось бы также обсудить вопрос характера изменений. Как вы их оцениваете?

А. С.

Как я уже отметил, художественные правки в ряде случаев перешли в новое качество. Однако и самих качественных изменений по сути не так уж мало, хотя, конечно, есть некоторые нюансы в том, что называть существенным изменением.

К примеру, в W3C продолжают изменять и уточнять права председателя консорциума (W3C Chair) и его директора (W3C Director). На мой взгляд, причина ясна: пользующийся всеобщим уважением Тим Бернерс-Ли (Tim Berners-Lee) не вечен, а существует эта крупная организация сейчас во многом благодаря ему и за счёт его авторитета. Видимо, в W3C всё чаще задумываются о том, что же будет, когда он покинет свой пост: права председателя W3C теперь несколько урезаны и введена должность административного директора (Chief Operating Officer — COO).

А. К.

Появление этой должности, на мой взгляд, можно приветствовать: желание разделить административные и стратегические задачи вполне естественно.

А. С.

Абсолютно согласен. Подозреваю, что такая должность уже существовала неформально (кто-то ведь должен был этим заниматься), в документе же её только формально «прописали».

Хочется добавить ещё несколько слов об изменении роли председателя и директора W3C: теперь председателем группы по технической архитектуре (Technical Architecture Group — TAG) не обязательно является директор. Считаю, это можно расценить как намёк на возможный уход Бернерса-Ли и появление неизбежно менее авторитетного человека в будущем.

Возвращаясь к нашей основной теме, нужно отметить, что стартовой (равно как и конечной) точкой процесса разработки спецификации теперь может являться записка рабочей группы (Working Group Note).

А. К.

Думаю, вы со мной согласитесь, это вполне обоснованный шаг. Ведь что такое по сути спецификация? Превращение идеи в некий документ. А ведь в записке зачастую оказывается эта самая идея.

А. С.

Конечно, вы правы. Однако ранее, если мне не изменяет память, источником таких идей служили в основном членские подачи (Member Submissions). Безусловно, в процессе функционирования рабочих групп появляется большое количество предложений, которые нельзя игнорировать. Вопрос лишь в том, как это отразится на работе самих рабочих групп. Мне кажется, что какими бы ценными эти записки не были, сотрудникам W3C не следует выпускать собственные документы в ущерб коллективной работе.

Кстати, в тексте указывается, что как членские подачи, так и подачи от сотрудников (Team Submissions) не являются частью процесса разработки рекомендации. Возможно, это будет служить неким ограничителем для рабочих групп.

А как вы отнеслись к появлению т. н. features at risk, то есть функционала в спецификации, который может быть удалён после периода реализации спецификации (Call for Implementations) в случае отсутствия его реализации?

А. К.

С одной стороны, мне это кажется разумным: всегда лучше подстраховаться. Кроме того, согласитесь, часто то, что кажется работоспособным, оказывается невыполнимым или плохо реализуемым. С другой стороны, так можно и весь функционал объявить рискованным.

А. С.

Мне тоже показалось, что это своевременное, я бы даже сказал, несколько запоздалое нововведение. Ведь нереализованные и нереализуемые функции в спецификациях проглядывают сплошь и рядом.

Всю спецификацию, конечно, можно назвать рискованной. Поясню, что я имею в виду. Если текст нежизнеспособен, то есть спецификацию продвигала, скажем так, определённая заинтересованная группа, которая реализовала документ ещё до поступления предварительного текста в W3C, то на этом этапе её можно попытаться отсеять, показать, что весь документ по существу нереализуем или реализуем в настолько узком сегменте, что едва ли возможно взаимодействие с остальным миром. Это — естественный отбор, если это понятие применимо к спецификациям.

Помимо этого, удалённый функционал, как вы знаете, можно включить в следующую версию документа.

А. К.

В связи с этим, как вы расцениваете требование о необходимости наличия двух случаев реализации каждой функции разрабатываемого стандарта для того, чтобы он стал рекомендацией?

А. С.

В данном случае нам следует уповать на Бернерса-Ли, главу W3C. Ведь в его праве пропустить спецификацию без удовлетворения этих требований. Появление же самого требования было важным шагом и с тех пор дела с реализациями спецификаций пошли, как мне кажется, чуть лучше.

Согласитесь, наличие пусть не 500, а 300 членов, просто обязывает кого-то из них реализовать спецификацию. Если же некому, то незачем её разрабатывать: рынок такой продукт не примет. W3C на собственном опыте убедился, что без учёта рынка действовать нельзя. Поэтому, на мой взгляд, следует ещё больше ужесточить требования к реализации функционала спецификаций. Хотя действовать необходимо осторожно: меня беспокоит тенденция к сокращению количества членов W3C.

Возвращаясь к разговору о разделе, регламентирующем процесс разработки рекомендаций W3C, хочу сказать, что мне он понравился. Расцениваю его, как продолжение развития W3C, отказ от ребячества и наивности, связанной с малыми размерами Сети в первые годы её существования. Очевидно, что W3C полагал, что рекомендация будет жить вечно, но уже в самом начале стало ясно о неосуществимости такой установки. Однако соответствующие изменения всё время откладывались — видимо, из желания сохранить имидж стабильности и монолитности.

А. К.

Подтверждением тому, на мой взгляд, является появление подраздела, регламентирующего процедуру аннулирования рекомендации (п. 7.7), а также раздела о внесении изменений (п. 7.6). Мне кажется, что в целом документ более приближен к жизни.

А. С.

К слову, следующая редакция (от 5 февраля 2004 года) этого документа допускает ещё одно новшество: переход от спецификации в статусе предложенной рекомендации (Proposed Recommendation) к статусу рекомендации-кандидата (Candidate Recommendation), как сказано, при наличии вопросов, связанных с реализацией.

В целом, если оценивать новую версию собственного поведения W3C, то проблемных мест стало гораздо меньше, а сам процесс, как вы верно заметили, стал более жизненным. Не могу сказать, как это скажется на скорости разработки стандартов: это мы увидим чуть позже. В любом случае в 2004 году нас ожидает урожай рекомендаций. И первые ростки уже показались.

А. К.

Интересный прогноз. Не могли бы вы рассказать об этом поподробнее?

Дело Eolas против Microsoft В 1999 году фирма Eolas Technologies совместно с Калифорнийским университетом подали иск на сумму 521 млн. долларов о нарушении корпорацией Microsoft патента № 5 838 906, принадлежащего этим организациям. Патент выдан на «метод автоматического вызова внешнего приложения, обеспечивающего взаимодействие и отображение встроенных объектов в гипердокументе». Таким образом, под действие патента попадают все страницы интернета, использующие элементы embed и object, а также обозреватели, позволяющие автоматически отображать подобные страницы. По заявлению истцов, Microsoft без всякого согласия с их стороны использовала в своем обозревателе Internet Explorer технологии, разработанные в 1994 году профессором Калифорнийского университета и исполнительным директором Eolas Майклом Дойлом (Michael Doyle) и двумя его коллегами. По их словам данные технологии защищены патентом от 1998 года. Корпорация Microsoft уведомила W3C о том, что она собирается внести в Internet Explorer изменения, связанные с иском. Изменения, в частности, состояли в том, что при обнаружении на странице упомянутых выше элементов, обозреватель выдавал предупреждающее окно для каждого из элементов. По мнению W3C, подобные изменения могут оказать существенное влияние не только на Microsoft, но и на другие компании, выпускающие обозреватели, (среди них Mozilla, Opera и Apple), поскольку все они используют технологию плагинов. Вследствие этого в сентябре 2003 года W3C решил организовать консультативную группу по патентам HTML (HTML Patent Advisory Group — HTML PAG), которой было необходимо изучить возможные последствия удовлетворения иска. В октябре этого же года W3C отправил в Бюро патентов и торговых марок США заявку, в которой перечислил некоторые предшествующие патенту изобретения, суть которых сводится к тому, что патент недействителен. Вскоре после этого Тим Бернерс-Ли, директор W3C, направил директору Бюро патентов и торговых марок США письмо, в котором потребовал признать патент недействительным, заявив, что это «предотвратит нанесение значительного экономического и технического ущерба Всемирной сети». В феврале 2004 года Бюро по патентам и торговым маркам США выпустило предварительное заключение о том, что патент № 5 838 906 недействителен. Eolas может опротестовать решение в течение двух месяцев.

А. С.

Думаю, это заметил любой, кто заглядывает на страницу технических отчётов W3C. Количество отчётов, приближающихся к финальным стадиям велико, а в 2003 году темпы роста количества рекомендаций упали. Вернее сказать, в 2003 году было выпущено даже меньше рекомендаций, чем в 2002, если не ошибаюсь. Довольно большая часть из того, что консорциум не успел принять в прошлом году, будет принята в этом. Полагаю, вы это также заметили.

А. К.

Разумеется, но вы это связываете с «естественным циклом» работ над техническими отчетами или здесь есть какие-то другие причины? И каково, на ваш взгляд, может быть влияние новой версии процесса принятия рекомендации?

А. С.

Отчасти это и естественный цикл, отчасти разрастание аппарата W3C: такое количество различных рабочих групп трудно было представить несколько лет назад. Не хотелось бы гадать на кофейной гуще относительно роли новой версии документа.

А. К.

Как по-вашему это отразится на сроках работы с документами и процессе принятия, отклонения и учёта выявленных недостатков?

А. С.

Думаю, если управление консорциума не будет предпринимать решительных шагов, ситуация не изменится.

Вот проблема, о которой я уже писал на xmlhack.ru: формально коллегиальная работа на деле превращается в авторство одного-двух человек. Это ненормальная ситуация, и выход я вижу опять только в жёстком подходе со стороны руководства.

Хотя надо признать, что руководство консорциума предпринимает и решительные меры. Вы следите за ситуацией вокруг дела Eolas против Microsoft?

А. К.

Да, и последняя информация, которой я располагаю на данный момент, заключается в том, что Бюро патентов и торговых марок США признало недействительным патент, выданный Eolas, и, таким образом, претензии Eolas были отклонены. Хотелось бы подчеркнуть, что прошлогоднее выступление главы W3C произвело на меня большое впечатление.

А. С.

Порадовали решительность действий и незамедлительность реакции. Безусловно, на представителей бюро повлияло документальное присутствие такой организации как W3C.

А. К.

Могу только с вами согласится и от себя добавить, что, если иск, который наверняка затянется на много лет, будет удовлетворён, это отрицательно скажется на всех, кто использует интернет и связанные с ним технологии.

Заключение

Широкая популярность и повсеместное признание языка XML — результат деятельности международных органов стандартизации и, в первую очередь, международного консорциума W3C. Значимость спецификаций, разрабатываемых этой организацией трудно переоценить. Однако, не меньший интерес и значение представляет документ, регулирующий работу самого консорциума и процесс разработки спецификаций.

В этой статье мы рассмотрели последние изменения в этом документе. Надеемся, что выбранная нами форма подачи материала не разочаровала читателя. Мы намерены и впредь следить за деятельностью W3C и информировать читателей обо всех изменениях в документе, регламентирующем разработку рекомендаций.

Автор: Александр Кудинов, компания Intersoft Lab, Александр Савенков, независимый консультант