GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
Математика + HTML = MathML(10972)
Кросс-браузерность: теория и практика(8384)
W3C будет вести себя так, как сам напишет(8069)
Международный консорциум W3C: от Рабочего проекта до Рекомендации(7869)
Немного слов о кодировках(7590)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » Спецификации » W3C будет вести себя так, как сам напишет

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


Intersoft Lab
market@iso.ru
http://www.iso.ru/

Дата: 07-04-2004
Автор: Александр Кудинов, компания Intersoft Lab, Александр Савенков, директор по маркетингу, ЗАО "Лаборатория массмедиа"

Предисловие

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

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

Консорциум W3C

Консорциум Всемирной сети (World Wide Web Consortium — W3C), созданный в октябре 1994 года, призван раскрыть весь потенциал Всемирной сети путём разработки общих протоколов, способствующих её развитию и взаимодействию внутри неё. W3C насчитывает около 400 членов со всего мира. Консорциум пользуется международным признанием благодаря своему вкладу в развитие Сети.

Хотя W3C издаёт спецификации, которые технически являются просто предложениями (или, в терминах W3C, рекомендациями) для дальнейшей реализации, они имеют свойство превращаться в стандарты де-факто. Спецификации получают статус рекомендации после того, как рабочий проект спецификации (Working Draft) становится рекомендацией-кандидатом (Candidate Recommendation), редакцией документа, передаваемой на рассмотрение разработчикам с целью тестирования и внедрения, а затем и предложенной рекомендацией (Proposed Recommendation), документом, по которому ожидается голосование членов W3C.

В этой статье речь пойдет не о стандартах, которые публикует 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.

А. К.

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

Подробный список изменений в документе

Изменения в редакции от 18 июня 2003 года
  • Документ стал более упорядоченным, все данные, касающиеся одного понятия, собраны в отдельных разделах. Уточнён и упрощён язык документа. Выделены слова must, may, should и т. п. по всему документу.
  • Изменены права председателя W3C. Председателем консультативного комитета (Advisory Board) не обязательно является председатель. Введены даты вхождения в должность и выхода из неё для членов консультативного комитета. Председателем группы по технической архитектуре не обязательно является директор.
  • Появилась должность административного директора, занимающегося организационной деятельностью.
  • Головные организации W3C явно заявлены как нечлены.
  • В разделе 2.1.1 появилось указание на то, что члены W3C честно следуют регламенту, и в случае постоянного его нарушения и при условии, что попытки директора решить эти проблемы не принесли никаких плодов, могут применяться дисциплинарные наказания, суть которых открыта только для членов.
  • Новое введение показывает, как работает весь регламент W3C и сам Консорциум.
  • Раздел 2.5.2: упрощён процесс обращения с вакантными местами в консультативном комитете, при смене места работы, сотрудник может остаться в совете до следующих выборов. Специальных выборов более нет, если сотрудник ушёл, место остаётся вакантным.
  • Указаны даты вступления в должность и выхода из неё для членов группы по технической архитектуре. Таким образом, интервал между назначениями в консультативный комитет и группу равен шести месяцам (что соответствует старому документу).
  • Раздел 3: улаживает вопросы голосования, консенсуса и встреч для всех групп.
  • Раздел 3.1.1: уточнение политики разрешения конфликтов и приводит несколько примеров.
  • В разделе 3.4 собраны и прояснены вопросы голосования. За организацию может быть подан один голос. Связанные члены считаются одной организацией. Если приглашённый эксперт представляет организацию, он обязан её объявить (опять же один голос). Рекомендовано включать в устав программы описание процедуры голосования (хотя акцент по-прежнему делается на голосование).
  • Новый раздел 4.1 уточняет уровни конфиденциальности ресурсов W3C.
  • В этой версии нет изменений, связанных с правами на интеллектуальную собственность, один произведены в следующей редакции.
  • Описание рекомендации изменено с целью фокусирования на достижении статуса рекомендации.
  • Новые разделы 7.2, 7.3, описывающие ожидания от рассмотрения документа и требования на этапе любого перехода.
  • Раздел 7.4.2: уточнение некоторых положений касательно Last Call. Теперь этот статус сигнализирует о том, что рабочая группа считает выполненными все требования, включая предъявленные другими группами. Рабочие группы должны работать с другими группами до Last Call для исключения неожиданностей.
  • Новый раздел 7.4.6, описывающий, что означает возвращение документа в рабочую группу для дальнейшей работы.
  • Раздел 7.6: процедуры изменения рекомендации, включая процесс внесения нормативных исправлений без немедленной повторной публикации. Новые разделы 7.6.1 об управлении списком ошибок и 7.6.2 о видах изменений в рекомендации.
  • Новый раздел 7.7: процедура аннулирования рекомендации W3C.
  • Предложения по ускоренному получению рекомендации, включая предложения в устав или программу для оповещения членом о процессе разработке.
  • Все возвращения на документ должны публиковаться, даже если они анонимны.
  • После Last Call может быть опубликован рабочий проект (если нет значительных изменений), после чего может последовать продвижение до рекомендации-кандидата.
  • Наименование «Записка» (Note) более не используется. Появление «Записки рабочей группы», «Членской подачи» и «Подачи от сотрудников».
  • Раздел 6.2.1: уточнено определение участника рабочей группы (в целях рабочей группы по патентам).
  • Раздел 6.2.1.7: требование «быть на хорошем счету». Притом, что все участники, представляющие организацию должны посещать собрания, для удовлетворения этого требования достаточно присутствия одного сотрудника от организации (такое может происходить, например, по причине высокой стоимости перелёта).
  • Раздел 6.2.6: уставы рабочих и специальных групп (Interest Groups) должны быть публичными.
  • Раздел 6.2.7: как минимум раз в три месяца рабочая группа должна публиковать технический отчёт.
  • Разделы 8.2, 8.3: упрощение процедуры голосования и 1 неделя для апелляции.
  • Новый раздел 10: добавляет способ создания формального контакта для координированной работы между W3C и организацией-партнёром. Положение, согласно которому директор может подписать меморандум договорённости (Memorandum of Understanding — MoU) с другими организациями.
  • Раздел 11.1.1: охват подач. Если технология находится в одной области с работой, выполняемой рабочей группой, члены должны принять участие в рабочей группе и внести свой вклад в разрабатываемую технологию. Членские подачи и подачи от сотрудников более не публикуются на странице технических отчётов.
  • Добавлены примеры случаев, когда может возникнуть конфликт интересов.
  • Обязательна diff-версия.
  • Между рабочим проектом и Last Call можно опубликовать ещё документ такого же статуса (без существенных изменений).
  • Во время периода реализации рабочая группа может определить features at risk и удалить их при продвижении документа до предложенной рекомендации.
  • Каждая функция спецификации должна иметь две рабочие взаимодействующие реализации. Требование не обязательно: директор вправе его не применять.
Изменения в редакции от 5 февраля 2004 года
  • Практически все изменения в данной редакции были направлены на согласование процедурного документа с патентной политикой W3C (W3C Patent Policy).
  • Раздел статуса: новое положение о нормативной связи между процедурным документом и патентной политикой.
  • Раздел 2.5.1: уточнение о природе членства в группе по технической архитектуре и консультативном комитете.
  • Раздел 2.5.3: требование «быть на хорошем счету» указано лишь как одна из причин (а не единственная), из-за которой председатель может попросить выйти из группы.
  • Новый раздел 3.6: отказ от должности в группе, к чему могут вынудить патентные обязательства.
  • Удалён старый раздел 4.
  • Раздел 6.1 о требованиях ко всем рабочим, специальным и координационным группам: уточнение о том, что председатель является представителем организации-члена, одним из сотрудников W3C или приглашённым экспертом.
  • Раздел 6.2.1 о требованиях к участию в рабочих и специальных группах: в целях согласования с патентной политикой даны более чёткие определения начальной и конечной точкам участия в группе.
  • Раздел 7.4.4: возможность перейти от предложенной рекомендации к рекомендации-кандидату.
  • Раздел 7.8: редакторы рабочей группы должны быть членами рабочей группы.

Заключение

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

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

 
25.05.2004
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.