О спецификации XHTML

3.3 О спецификации XHTML

В настоящей спецификации определяется XHTML 1.0, переформулировка HTML 4 в виде приложения XML 1.0, и три DTD, соответствующих типам, определяемым HTML 4. Семантика элементов и их атрибутов определена в рекомендации W3C HTML 4. Данная семантика представляет собой основу для будущего расширения языка XHTML.

XHTML представляет собой семейство имеющихся на данный момент и могущих появиться в будущем типов документов и модулей, являющихся копиями, подмножествами или расширениями языка HTML 4 [HTML]. Семейство типов документов XHTML базируется на XML и предназначено для работы с пользовательскими агентами на базе. Более подробную информацию об этом семействе и его эволюции можно найти в разделе "Направления развития".

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

Преимущества перехода на XHTML 1.0 описаны выше. Вот несколько основных преимуществ:

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

Постоянно вводятся альтернативные методы доступа в Интернет. По некоторым оценкам, в 2002 году 75% обращений к документам в Интернет будет выполняться с альтернативных платформ. Семейство XHTML создавалось с учетом общей совместимости пользовательских агентов. С помощью нового механизма профилирования пользовательских агентов и документов серверы, прокси и пользовательские агенты смогут преобразовывать содержимое наилучшим образом. В конечном счете станет возможной разработка соответствующего XHTML содержимого, пригодного для любого соответствующего XHTML пользовательского агента.

В настоящей спецификации используются следующие термины, которые расширяют определения, данные в [RFC2119] аналогично определениям ISO/IEC 9945-1:1990 [POSIX.1]:

Описываются общие термины XHTML: атрибут, DTD, возможности, документ, пользовательский агент, правильно построенный, представление (генерация), проверка корректности, реализация, синтаксический разбор, элемент.

В настоящей версии XHTML предоставляется определение строго конформных документов XHTML.

Строго конформный документ XHTML - это документ, которому необходимы только возможности, описанные в настоящей спецификации как обязательные.

Пространство имен XHTML может использоваться с другими пространствами XML в соответствии с [XMLNAMES], хотя такие документы не являются строго конформными XHTML 1.0 в соответствии с приведенным выше определением. В будущих работах W3C будут определены способы указания конформности документов, в которых используется несколько пространств имен.

Конформный пользовательский агент должен соответствовать всем определенным в спецификации критериям.

Говорится о различиях которые присутствуют в языке XHTML. Поскольку XHTML является приложением XML, некоторые приемы, допустимые в языке HTML, основанном на SGML, должны быть изменены.

К документам XHTML 1.0 не предъявляется требование совместимости с существующими пользовательскими агентами, но на практике оно достаточно легко реализуемо.

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

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

Процесс модуляризации разбивает XHTML на ряд более мелких подмножеств элементов. Модуляризация дает определенные преимущества.

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

Для авторов профили устраняют необходимость написания нескольких различных версий документов для различных клиентов.

Глава 4. РЕАЛИЗАЦИЯ ТЕХНОЛОГИЙ WEB В ИНФОРМАЦИОННОЙ СИСТЕМЕ «УЧЕБНО-МЕТОДИЧЕСКИЙ РЕСУРС»

Разработка информационной системы «Учебно-методический ресурс» включает в себя создание двух подсистем: главной страницы (страницы навигации) и шаблона исходного представления документа.

Для создания этих двух частей выбран табличный дизайн. Он организуется с помощью таблиц. Таблицы используется для организации расположения на страницах текстовой и числовой информации в табличном формате, а также это инструмент для точного позиционирования объектов на Web-странице. Истинная ценность таблиц заключается в возможности их применения для компоновки страниц. HTML-таблицы позволяют компоновать такие Web-страницы, создание которых было достаточно сложным, если не вовсе невозможным, до введения таблиц.

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

<td link="99CC99" vlink="99CC99" alink="99CC99" width="20%">

 <div align="left"><a href="users/UMR/lec.htm"><img src="users/UMR/ris/button_lec.gif" width="195" hight="44" border="0"></a></div>

 <p align="left"></p>

 <div align="left"><a href="users/UMR/lab.html"><img src="users/UMR/ris/button_lab.gif" width="195" hight="44" border="0"></a>

 </div>

 <p align="left"></p>

 <div align="left"><a href="users/UMR/kontr.htm"><img src="users/UMR/ris/button_kontr.gif" width="195" hight="44" border="0"></a>

 </div>

 <p align="left"></p>

 <div align="left"><a href="users/UMR/ind.htm"><img src="users/UMR/ris/button_ind3.gif" width="195" hight="44" border="0"></a>

 </div>

 <p align="left"></p>

 <div align="left"><a href="users/UMR/sam.htm"><img src="users/UMR/ris/button_sam.gif" width="195" hight="44" border="0"></a>

 </div>

 <p align="left"></p>

 <div align="left"><a href="users/UMR/dop.htm"><img src="users/UMR/ris/button_dop.gif" width="195" hight="44" border="0"></a>

 </div>

 <p align="left"></p>

 <div align="left"><a href="users/UMR/gloss.htm"><img src="users/UMR/ris/button_gloss.gif" width="195" hight="44" border="0"></a>

 </div>

</td>

Для описания таблиц используется тег <ТАВLЕ>. Тег <ТАВLЕ>, как и многие другие, автоматически переводит строку до и после таблицы.

Создание строки таблицы — тег <ТR>. Тег <ТR> создает строку таблицы. Весь текст, другие теги и атрибуты, которые требуется поместить в одну строку, должны размещаться между тегами <ТR></ТR>.

Определение ячеек таблицы - тег <ТD>. Внутри строки таблицы обычно размещаются ячейки с данными. Каждая ячейка, содержащая текст или изображение, должна быть окружена тегами <ТD> </ТD>. Число тегов <ТD> </ТD> в строке определяет число ячеек (открыть). Например:

 <TABLE>

 <TR>

 <TD COLSPAN=3>В таблице два тега TR значит в ней две строки.</TD>

 </TR>

 <TR>

 <TD>В строке три тега TD</TD>

 <TD>значит</TD>

 <TD>три столбца.</TD>

 </TR>

 </TABLE>

Для эффективного использования таблиц необходимо применять специальные тэги и атрибуты. Например:

·           Тег <ТН> — заголовки столбцов таблицы.

·           Тег <САРТIОN> — использование заголовков таблицы.

·           Атрибут NOWRAP

·           Атрибут СОLSPAN

·           Атрибут ROWSPAN

·           Атрибут WIDТН

·           Атрибут СЕLLРАDDING

·           Атрибут CELLSPACING и другие.

При создании любого HTML документа можно говорить, что текст – это единственный объект Web-страницы, который не требует специального определения. Иными словами, произвольные символы интерпретируются по умолчанию как текстовые данные. Но для форматирования текста существует большое количество элементов.

<р></p> - Элемент абзаца (paragraph).

<BR> - Элемент, обеспечивающий принудительный переход на новую строку.

<pre></pre> - Элемент для обозначения текста, отформатированного заранее (preformatted).

<blockquote></blockquote> - Обозначение цитаты

<center></center> - Элемент используется для центрирования текста, а точнее, любого содержимого.

<div></div> - Элемент, похожий на предыдущий. Он позволяет выравнивать содержимое по левому краю, по центру или по правому краю. Для этого стартовый тег должен содержать соответствующий атрибут:

align=”left”

align=”center”

align=”right”

<b></b> - Выделение текста полужирным шрифтом.

<font></font>

Определение типа, размера и цвета шрифта. Все эти характеристики определяются при помощи соответствующих атрибутов. Например, абсолютный размер шрифта задается при помощи size (размер):

 size=Абсолютный размер шрифта

Размер шрифта может задаваться относительно базового:

size=+Число

size=-Число

При назначении величины для size необходимо учитывать величину базового размера. Обе они в сумме должны соответствовать одному из абсолютных размеров. Так для базового размера, равного 3, относительный размер может находиться в пределах от -2 до +4. Если величина выходит за допустимый предел, то используется или шрифт размера 7, или шрифт размера 1.

Для элемента FONT можно использовать атрибут цвета:

color=”цвет”

Атрибут face (вид) также можно использовать для элемента font. Он позволяет задавать тип шрифта:

face=’’Название шрифта’’

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

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

ЗАКЛЮЧЕНИЕ

Создание Web пoпpaвy мoжнo cчитaть oдним из кpyпнeйшиx нayчнo - тexнических достижений последнего десятилетия XX века. Благодаря реализации этого проекта рождается целый ряд новых информационных технологий, имеющих весьма значимые социально-экономические последствия.

Одним из наиболее распространенных классов систем обработки данных являются информационные системы. В настоящее время усиливается тенденция глобализации ИС.

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

Главное преимущество Web-технологий в современных условиях заключается в их простоте и как следствие в повышении эффективности их применения.

В этой курсовой работе мы попытались показать обширную проблематику технологий современных информационных систем, технологий Web, появления новых тенденций в развитии технологий Web. В данной работе проанализированы необходимые для данной курсовой работы спецификации и разработан фрагмент информационной системы «Учебно – методический ресурс».

Список испольЗОВАННЫХ источников

1.   Баранов, Д.В. Современные информационные технологии. / Д.В. Баранов. – Томск: ИДО (ТУСУР), 2005. – 130 с.

2.   Ваулина, Ч.Ю. Информатика: толковый словарь / Ч.Ю. Ваулина. – М.: Изд-во Эксмо, 2005. – 480 с.

3.   Когаловский, М.Р. Перспективные технологии информационных систем / М.Р. Когаловский. – М.: Компания АйТи, 2003. – 288 с.

4.   Когаловский, М.Р. Энциклопедия технологий баз данных / М.Р. Когаловский. – М.: Финансы и статистика, 2005. – 800 с.

5.   Крис, Д. Креативный Web-дизайн. HTML, XHTML, CSS, JavaScript, PHP, ASP, ActiveX. Текст, графика, звук и анимация. Учебник Пер с англ. / Д. Крис, К. Кинг, Э. Андерсон. – М.: ООО «ДиаСофтЮП», 2005. 672 с.

6.   Мишенин, А.И. Теория экономических информационных систем / А.И. Мишенин. – М.: Финансы и статистика, 2002. – 240 с.

7.   Непейвода, Н.Н. Основания программирования / Н.Н. Непейвода, Скопин И.Н. – Москва-Ижевск: Институт компьютерных исследований, 2003. – 868 с.

8.   Основы Web – технологий : учеб. пособие / П.Б. Храмцов [и др.]. – М. : Изд-во Интуит.ру “Интернет-Университет Информационных Технологий”, 2003. – 512 с.

9.   Пауэл Томас, А. Справочник программиста / Томас А Пауэл, Д. Уитворт. – М.: АСТ, Мн.: Харвест, 2005. – 384 с.

10.      Петров, В.Н. Информационные системы: учеб. пособие / В.Н. Петров. – СПб.: Питер, 2002. – 588 с.

11.            Экономическая информатика: Введение в экономический анализ информационных систем: учебник. – М.: ИНФРА-М, 2005. – 958 с. – (Учебники экономического факультета МГУ им. М.В. Ломоносова).

12.            Когаловский М.Р. XML: возможности и перспективы [Электронный ресурс] / сост. и ред. М.Р. Когаловский – OSP.RU:Издательство "Открытые системы", [2001]. <http://www.osp.ru/cio/2001/02/016.htm> (15.02.2001).

13.      Когаловский М.Р. XML:сферы применений [Электронный ресурс] / сост. и ред. М.Р. Когаловский – OSP.RU:Издательство "Открытые системы", [2001]. <http://www.osp.ru/cio/2001/04/010.htm> (17.04.2001).

14.      Когаловский М.Р. Развитие стандартов XML: новые возможности и применения [Электронный ресурс] : (Материалы Второй всероссийской конференции «Стандарты в проектах современных информационных систем») [тез. докл.] / М.Р. Когаловский Институт проблем рынка РАН < http://www.cemi.rssi.ru/mei/articles/conf02st.htm> (27-28.03.2002).

15.      Международная организация OASIS: сообщество рабочих групп Журнал: Intersoft Lab [Электронный ресурс] Новая деловая газета: CitCity [Web-сайт]. 24.02.1997// <http://www.citforum.ru/internet/xml/oasis/> (09.04.2003).

16.      Международный консорциум W3C: от Рабочего проекта до Рекомендации Журнал: Intersoft Lab [Электронный ресурс] Новая деловая газета: CitCity [Web-сайт]. 24.02.1997// <http://www.citforum.ru/internet/ xml/w3c/> (08.04.2003).

17.      Российские Электронные Библиотеки Extensible Hypertext Markup Language (XHTML) [Электронный ресурс] / Аннотированный указатель стандартов платформы XML <http://www.elbib.ru/index.phtml?page= elbib/rus/methodology/xmlbase/standarts_2002/XHTML > (13.01.2006).

18.      Российские Электронные Библиотеки Hypertext Markup Language (HTML) [Электронный ресурс] / Аннотированный указатель стандартов платформы XML) / <http://www.elbib.ru/index.phtml?page=elbib/rus/ methodology/xmlbase/standarts_2002/HTML > (23.12.2003).

19.      Extensible Markup Language (XML) [Электронный ресурс] / Спецификация <http://www.w3.org/XML/ >.

20.      OASIS Advancing E-Business Standart Since [Электронный ресурс] / <http://www.oasis-open.org/> (1993).

21.      Simple Solutions – разработка и сопровождение Web-сайтов. Введение в учебник HTML, немного истории [Электронный ресурс] / Web-студия Ретюхина Александра <http://www.sasha.by/doc2.php?page=html& theme=0> (2000-2006).

22.      Simple Solutions – разработка и сопровождение Web-сайтов. PHP и XML. [Электронный ресурс] / Web-студия Ретюхина Александра <http://www.sasha.by/doc2.php?page=html&theme=1> (2000-2006).

23.      Simple Solutions – разработка и сопровождение Web-сайтов. Основные понятия [Электронный ресурс] / Web-студия Ретюхина Александра <http://www.sasha.by/doc2.php?page=html&theme=1> (2000-2006).

24.      World Wide Web Consortium W3C, World Wide Web, Web, WWW, Consortium, computer, access, accessibility, semantic, worldwide, W3, HTML, XML, standard, language, technology, link, CSS, RDF, XSL, Berners-Lee, Berners, Lee, style sheet, cascading, schema, XHTML, mobile, SVG, PNG, PICS, DOM, SMIL, MathML, markup, Amaya, Jigsaw, free, open source, software [Электронный ресурс] / < http://www.w3.org/> (03.1989).

25.      XHTML 1.0: The Extensible HyperText Markup Language (Second Edition) [Электронный ресурс] / Спецификация <http://www.w3.org/ TR/xhtml1> (26.01.2000, 01.08.2002).

26.      HTML 4.01 Specification [Электронный ресурс] / Спецификация < http://www.w3.org/TR/html4 > (24.12.1999).

Приложение 1. Международный консорциум W3C

В настоящий момент "на ниве стандартизации" плодотворно трудится целый ряд различных международных и национальных органов, включая такую авторитетную организацию, как ISO (International Standards Organization, Международная организация по стандартизации). То, что мы остановились на W3C и OASIS, объясняется исключительно XML-направленностью данной рубрики. Кроме того, эти консорциумы являются наиболее авторитетными и известными организациями в области XML-технологий (сразу оговоримся, что мы нисколько не пытаемся принизить значимость других объединений, как, например, XBRL Inc. или WS-I, - изучив принятые в этих органах правила и нормы принятия стандартов, можно говорить об общности подходов при их разработке и утверждении).

Немного истории

World Wide Web Consortium (W3C) - это международная организация, объединяющая в своих рядах около 450 членов и постоянный штат из более чем 60 сотрудников. W3C был создан в октябре 1994 года по инициативе Тима Бернерса-Ли (Tim Berners-Lee), создателя "всемирной паутины", на базе Лаборатории вычислительной техники Массачусетского технологического института (Massachusetts Institute of Technology, Laboratory for Computer Science) при активном участии Европейской организации по ядерным исследованиям (Conseil Europeen pour la Recherche Nucleaire, CERN), Управления перспективных исследовательских программ (Defense Advanced Research Projects Agency, DARPA) и Европейской комиссии (European Commission). В апреле 1995 года европейское представительство консорциума "приютил" Национальный институт исследований в области компьютерной обработки данных и автоматики (Institut National de Recherche en Informatique et en Automatique, INRIA), а в 1996 году - появилось азиатское отделение - инициатором выступил японский центр Shonan Fujisawa Campus (Keio University of Japan). Наконец, в этом году Европейскому научно-исследовательскому консорциуму в области информатики и математики (European Research Consortium on Informatics and Mathematics, ERCIM) "были переданы функции" INRAI.

Организационная структура

Как отмечалось выше, основу W3C составляют его члены: поставщики продуктов и услуг, корпоративные пользователи, исследовательские лаборатории, органы стандартизации, правительства различных стран. Члены организации направляют технических специалистов и своих представителей для участия в работе различных групп консорциума: Рабочих групп (Working Group), Неспециализированных групп (Interest Group) и Координационных групп (Coordination Group) - руководство которыми осуществляет персонал W3C, или так называемая Целевая группа (Team). В этих группах выполняется львиная доля работы консорциума - результатом их деятельности являются технические отчеты, программные средства с открытым кодом и различные услуги.

Организационно, все работы в консорциуме ведутся по так называемым направлениям деятельности (Activity). Цели и задачи каждого такого направления излагаются в Декларации направления (Activity statement), в котором приводится список задействованных групп.

От предложения до рекомендации

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

В процессе рассмотрения различных заявок и замечаний, направляемых членами консорциума, организации конференций и семинаров, а также отслеживания развития Web-технологий, руководство W3C - Team - может прийти к выводу о необходимости формирования нового направления деятельности. С этой целью Директор (Director) направляет в Консультативный комитет (Advisory Committee) предложение о формировании нового направления деятельности (Activity Proposal). В течение периода рассмотрения, который длится не менее месяца, Консультативный комитет высказывает свои соображения и замечания по обсуждаемому вопросу, после чего Директор информирует комитет об отношении членов консорциума к этому предложению. При наличии консенсуса, то есть если эта идея получила всеобщую поддержку, W3C инициирует новое направление.

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

Примечания - это различные документы, комментарии, мнения членов консорциума и представителей общественности. К ним также относятся заявки на рассмотрение, направляемые членами W3C, и различные информационные ресурсы, сформированные в процессе работы какой-либо рабочей группы или Целевой группы.

Технический отчет представляет собой одну из возможных версий стандарта, разрабатываемого рабочей группой: Рабочая версия (Working Draft), Последняя редакция Рабочей версии, или Рабочей версия в статусе "крайнего срока" (Last Call Working Draft), Кандидат к рекомендации (Candidate Recommendation), Предложенная рекомендация (Proposed Recommendation) и Рекомендация (Recommendation).

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

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

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

Остановимся более подробно на процедуре разработки и принятия различных версий стандартов W3C. Для этого рассмотрим рис. 1. ниже.

Рис. 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 дней, если это очная встреча.

·      Предполагаемый график заседаний на первый год.

·      Имена и электронные адреса членов Технического комитета (не менее трех человек).

·      Имя председателя комитета.

·      Имена возможных устроителей совещаний.

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

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

Согласно Регламенту технических комитетов OASIS (OASIS Technical Committee Process) консорциум принимает и публикует два типа технических материалов: Спецификации комитетов (Committee Specification) и Стандарт OASIS (OASIS Standard).

Спецификация комитета

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

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

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

Стандарт OASIS

Стандарт OASIS - это Спецификация комитета, которая после представления членам консорциума на рассмотрение, была одобрена в ходе проведенного голосования.

Прежде чем внести Спецификацию на утверждение, предлагаемая Спецификация должна быть передана "на суд общественности". Цель этого шага - а на изучение должно быть отведено не менее одного месяца - гарантировать, что документ достоин выдвижения на статус Стандарта (при этом, комитет может провести несколько циклов рассмотрения с последующим голосованием на предмет окончательного утверждения документа в качестве Спецификации комитета). После чего Технический комитет должен решить путем голосования, направлять ли данную Спецификацию на соискание статуса Стандарта. В случае положительного результата председатель комитета направляет Управляющему технических комитетов до 15-го числа любого месяца документ, который должен содержать следующую информацию:

·      Спецификацию и соответствующую документацию.

·      Краткое изложение Спецификации, написанное на английском языке.

·      Сертификат, подтверждающий, что по крайней мере три организации-члена OASIS успешно используют Спецификацию. Кроме того, лица, выдавшие свидетельство об применении Спецификации, должны подтвердить, что ее реализация отвечает требованиям, принятым в OASIS в отношении прав на интеллектуальную собственность (IRP Policy).

·      Отчет об отзывах, полученных в ходе рассмотрения Спецификации.

·      Указание на архив комментариев, то есть на архивы списков рассылки и замечаний Технического комитета.

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

Чтобы получить статус Стандарта OASIS, Спецификация комитета должна получить не менее 10% голосов, однако, число проголосовавших против также должно быть не более 10%. В случае непринятия Спецификации Технический комитет может повторить ее представление на статус Стандарта.

Результаты голосования становятся известны в течение семи дней после окончания периода голосования. В случае положительного результата объявление о выходе нового Стандарта и сам Стандарт публикуются на сайте OASIS.

[1] Платформа — целенаправленно разработанная для решения некоторых задач совокупность технологий и поддерживающих их стандартов.

[2] Термин «слабоструктурированные данные» означает такие данные, которые в отличие от данных в БД не имеют регулярной структуры, определяемой с помощью предписывающей схемы.

[3] Метаданные — свойства данных, определяющие их структуру, допустимые значения и способы их представления, взаимосвязи с другими данными, размещение и другие характеристики данных, которые помогают правильно их интерпретировать и использовать. Иначе говоря, это данные о данных.

4 Информационный ресурс — используемые в приложениях данные, которые представлены в базах данных, базах знаний, на Web-сайтах, в отдельных файлах различной природы или в процедурной форме с помощью продуцирующих их программных средств.