Смекни!
smekni.com

Язык гипертекстовой разметки HTML в разработке информационных систем (стр. 10 из 11)

Рис. 1. Схематическое представление этапов стандартизации

Рабочая версия

Рабочая версия - это "первая ступень" в продвижении технического отчета к самому высокому статусу, который может получить спецификация - Рекомендации. Формально, для опубликования Рабочей версии необходимо согласие Директора, хотя факт обнародования документа не является отражением наличия консенсуса или одобрения со стороны W3C.

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

После выхода Рабочей версии группа должна продолжить работу над ней: принимать комментарии и замечания к данному документу как от членов W3C, так и "представителей общественности".

Последняя редакция Рабочей версии

Последняя редакция Рабочей версии - это "особый случай" Рабочей версии. Этот документ является результатом ее доработки на предмет соответствия требованиям Рабочей группы, а также формального разрешения всех вопросов, возникших в процессе ее изучения как самими ее авторами, так и другими Рабочими группами и "представителями общественности". Представляя спецификацию в статусе Последней редакции Рабочей версии, Рабочая группа рассылает запрос на участие в рассмотрении документа. К изучению спецификации привлекаются другие группы W3C, а также общественность. При этом, Рабочая группа должна установить период приема комментариев (как правило, он составляет три недели, хотя в случае, если технический отчет освещает достаточно сложные технические вопросы, указанный срок может быть продлен). На этом этапе к работе над спецификацией подключается Консультативный комитет, который всячески содействует получению отзывов и замечаний - для того, чтобы выявить все проблемы и вопросы до того, как спецификация перейдет в статус Кандидата к рекомендации.

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

Кандидат к рекомендации

Для получения статуса Кандидата к рекомендации Рабочая группа должна выполнить все требования, предъявляемые к Последней редакции Рабочей версии, формально разрешив все замечания, высказанные во время периода "крайнего срока" Рабочей версии, а также согласовать все вопросы, относящиеся к ведению других групп, а также предоставить список всех формальных возражений.

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

Фактически, переход спецификации в рассматриваемый статус означает, что Рабочая группа ожидает, что предложенный ею документ найдет практическое применение (два не связанных между собой случая реализации не являются обязательным требованием при получении данного статуса, однако, их наличие или указание о потенциально возможных решениях всячески приветствуются).

Как и в случае с Последней редакцией Рабочей версии, по окончании "кандидатского" периода Рабочая группа может обратиться к Директору с просьбой предоставить спецификации статус Предложенной рекомендации. В случае отказа, Директор обязан "понизить" документ до Рабочей версии, поставив в об этом в известность Консультационный комитет.

Предложенная рекомендация

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

Директор может обязать Рабочую группу разрешить все вопросы, поднятые членами Консультативного комитета в течение периода рассмотрения, который длится не менее одного месяца. Рабочая группа также должна формально ответить на вопросы, возникающие вне Консультативного комитета (в других рабочих группах и в среде общественности), своевременно сообщив об этом Директору.

По окончании данного этапа Директор может предоставить спецификации статус Рекомендации, в противном случае он обязан "понизить" документ до Кандидата к рекомендации или Рабочей версии.

Каким бы ни было его решение, Директор должен сообщить о нем Консультативному комитету не ранее двух недель после завершения периода рассмотрения Предложенной рекомендации. Однако, Директор обязан сделать объявление не позднее трех недель.

Рекомендация

Чтобы Предложенная рекомендация превратилась в Рекомендацию, Директор должен быть уверен, что она пользуется ощутимой поддержки со стороны Консультативного комитета, Целевой группы, рабочих групп W3C и общественности. Решение о предании документу статуса Рекомендации является решением W3C.

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

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

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

Приложение 2.

Международная организация OASIS.

История создания и краткая информация об организации

Organization for Structured Information Standards (OASIS, Организация по стандартизации структурированной информации) - международный, некоммерческий консорциум, объединяющий в своих рядах более 600 корпоративных и индивидуальных членов из различных стран мира. Вместе с ООН OASIS финансирует проект ebXML, спецификацию обмена данными электронного бизнеса. Кроме того, консорциум осуществляет управление XML.org, центром анализа и синтеза XML-схем, а также поддерживает Cover Pages, интерактивную коллекцию совместимых стандартов языков разметки.

Корни организации уходят в 1993 год, когда был основан консорциум SGML Open, цель которого состояла в разработке принципов согласованности продуктов, поддерживающих язык SGML. Чтобы соответствовать изменившимся реалиям: росту объема технических разработок, включая работу над языком XML и другими связанными стандартами, в 1998 году консорциум сменил название на нынешнее.

Общее руководство консорциумом осуществляет Совет директоров (Board of Directors), избираемый членами OASIS. Совет директоров состоит из восьми директоров, срок полномочий которых составляет два года.

Как и в международном консорциуме W3C, большая часть работы по созданию стандартов ведется в Технических комитетах (Technical Committee, TC). В состав комитетов может войти любое лицо, являющееся либо индивидуальным членом OASIS, либо служащим компании-члена OASIS, либо членом другой организации, которая располагает правами объединенного членства, или другим физическим лицом, в случае принятия Советом директоров соответствующего решения. Кроме того, в работе над спецификациями могут принимать участие лица, не являющиеся членами OASIS - несмотря на то, что они не располагают правом голоса, они могут выражать свое мнению по рассматриваемому вопросу, направляя отзывы в комитет (comment list).

Спецификации технических комитетов и стандарт OASIS

Первым шагом на пути становления стандарта является формирование списка обсуждения (discussion list), цель которого - обоснование необходимости создания технического комитета и обсуждение его задач, устава и т. п. Для этого не менее трех членов консорциума должны направить в Правление технических комитетов OASIS (OASIS TC Administration) соответствующую просьбу, указав потенциальные задачи будущего комитета, название списка обсуждения, имена лиц, участвующих в его формировании, контактную информацию, а также имя руководителя этого проекта.

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

Следующий шаг - обращение в Правление технических комитетов OASIS с предложением об образования Технического комитета. Такая заявка должна включать следующую информацию:

· Название Технического комитета.

· Декларация его задач.

· Перечень выходных документов комитета и планируемые сроки завершения работ.

· Язык проекта (работа в комитете может осуществляться на любом языке, однако, итоговый отчет о деятельности, представляемый членам OASIS на утверждение, должен быть написан на английском языке).

· Дата, время и место первого заседания комитета. Дата первого совещания должна быть назначена не ранее чем через 30 дней после объявления о создании комитета в случае, если планируется проведение телекоференции, и не ранее чем через 45 дней, если это очная встреча.