Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

28.03.2017

Google
WWW CITForum.ru
С Новым годом!
2004 г.

Спецификации XML 1.1 и "Пространства имен 1.1"

Автор: Арнод Ле Хорс (Arnaud Le Hors)
Перевод: Intersoft Lab

Что следует знать об этих спецификациях

Данная статья посвящена спецификациям XML 1.1 и Пространства имен 1.1. Ее автор, главный инженер отдела программного обеспечения корпорации IBM, Арнод Ле Хорс рассказывает об изменениях, внесенных в эти спецификации, о том, как эти изменения повлияют на другие спецификации и что это будет значить для пользователей.

4 февраля 2004г. консорциум W3C опубликовал едва ли не "в обстановке повышенной секретности" новую рекомендацию "Расширяемый язык разметки (XML), версия 1.1". В этой спецификации определяется новая версия ныне повсеместно распространенного формата XML. Если учесть значимость языка XML, можно предположить, что это событие должно было бы вызвать настоящую сенсацию, однако, прошло уже несколько месяцев, и лишь относительное очень немногие слышали о существовании XML 1.1. В чем же причина?

В этой статье содержится ответ на этот вопрос, в ней рассматриваются различия между XML 1.0 и XML 1.1, поясняется, что нужно знать о новой спецификации и о связанной с нею спецификацией - "Пространства имен в XML 1.1".

Почему W3C разработал XML 1.1

Когда в 1998г. W3C опубликовал XML 1.0, консорциум выбрал в качестве основы Unicode 2.0, тогдашнюю версию стандарта Unicode. Предназначение этого стандарта - установить уникальное число - код - для каждого существующего символа, благодаря чему все символы можно представлять и корректно обрабатывать компьютерами. Разумеется, присвоение числа каждому символу - это задача, на выполнение которой требуется время. По этой причине консорциум Unicode - орган стандартизации, занимающейся разработкой стандартов Unicode - работал над этим проектом в течение нескольких лет; почти каждый год эта организация выпускает новую версию своего стандарта, причем каждая версия включает целый ряд новых символов. Это означает, что системы, которые зависят от стандарта Unicode, должны проектироваться так, чтобы быть совместимыми вперед, либо корректироваться, чтобы соответствовать новым версиям Unicode.

К сожалению, при проектировании XML 1.0 не была заложена возможность полностью подстраиваться под новые версии Unicode. Несмотря на то, что символы, которые отсутствуют в Unicode 2.0, могут использоваться в символьных данных XML 1.0, они не допустимы в важных конструкциях XML, таких как имена элементов и атрибутов или перечисляемых значениях атрибутов.

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

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

Основные различия между XML 1.1 и XML 1.0

В самом начале работ над XML 1.1 члены рабочей группы XML Core обсуждали возможность изменения основы XML с Unicode 2.0 на последнюю изданную версию Unicode (тогда это была версия 3.0) посредством простого добавления новых символов в существующие конструкции. Однако, это было бы временным решением, поскольку после выхода еще нескольких версий Unicode, рабочей группе пришлось бы начинать все с самого начала. Именно поэтому члены группа избрали более радикальный подход: совместимость снизу вверх.

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

В отличие от XML 1.0, XML 1.1 совместим со стандартом Unicode снизу вверх. Это означает, что эта версия XML определена таким образом, что любой разработанный сегодня процессор XML 1.1. может обрабатывать документы, которые используют символы, назначенные только для будущих версий стандарта Unicode.

Каким образом это достигается? Дело в том, что XML 1.0, определяя конструкции, такие как имена элементов, явно допускает определенные символы и исключает любые другие. Таким образом, исключению подлежат все символы, которые еще не определены в Unicode. В случае XML 1.1 применяется противоположный подход: допускаются все возможные символы за исключением определенных символов. Как правило, такие символы либо имеют особое значение для процессоров XML, как, например, отрывающая угловая скобка (<) или символ пробела, либо использование таких символов, например, пустого символа (null character), чревато возникновением проблем. Этот подход означает, что символы, которые в будущем будут добавлены в Unicode, на самом деле уже допускаются в именах элементов и аналогичных конструкциях.

У данного подхода, однако, есть один небольшой изъян. Если потребуется использовать в XML-файле код, который еще не определен в Unicode - то есть этот код не соответствует любому реально существующему символу - процессор XML 1.1 обработает его таким, какой он есть, даже не сгенерировав простого предупреждения. Однако, в конечном счете указанные преимущества перевешивают этот недостаток - особенно если учесть, что в противном случае сначала пришлось бы генерировать такие символы, поскольку большинство инструментальных средств просто не позволяют их использовать.

Другие отличия

Начав работу над новой версией XML, членам рабочей группы показалось разумным исправить и некоторые другие недостатки тогдашней версии XML. Первый из них - это нестыковка между определением обозначением конца строки в XML и тем, как это определено в Unicode. Это несоответствие особенно влияет на IBM- и IBM-совместимые мейнфреймы, а также любые взаимодействующие с ними системы. На этих машинах инструментальные средства отмечают конец строки с помощью символа (NEL), который как таковой не признается XML 1.0. Это означает, что, если на этих системах создать XML-документ с помощью такого простого инструмента как Notepad, а потом передать его в процессор, совместимый с XML 1.0, созданный документ будет отвергнут как некорректно-оформленный. В XML 1.1 эта проблема решается путем добавления символа (#x85) в список символов, которые обозначают конец строки. Для полноты в этот список также включен символ разделителя строки (#x2028).

Кроме того, спецификация XML 1.1 разрешает добавлять в документы символы управления, используя ссылки на символы. Это касается символов управления, находящихся в диапазоне от #x1 до #x1F, большинство которых запрещено в XML 1.0.
Это означает, что теперь документы могут включать символ звуковой сигнализации, например, . Однако, эти символы пока не могут появляться непосредственно в документах, поскольку это нарушает определение типа mime, используемого для XML (text/xml) и может вызвать проблемы с инструментами, которые ожидают, что XML-файлы будут содержать только текстовые символы, и которые обрабатывают символы управления определенным образом.

Самое последние дополнение, внесенное в XML 1.1, это проверка нормализации символов. Несмотря на то, что изначально предполагалось, что Unicode определит уникальное число для каждого символа, определенные символы - или то, что пользователи считают символами - может на самом деле быть представлено несколькими способами.
Например, "e" с диакритическим знаком (’e в слове r’esum’e) обычно обозначает как одиночный код, присвоенный этому символу (#xE9) или как эквивалентная последовательность нескольких кодов (#x65 для "e" и #x301 для диакритического знака). Кроме того, у некоторых символов вообще нет кода, как, например, седиль у "e" (седиль - это знак, находящийся ниже символа "c" в "facade"). Поэтому их можно представить только комбинируя несколько кодов (в нашем примере, #xE9 для "e", за которым следует седиль - #x327). Существует неограниченное количество возможны комбинаций. В тех случаях, если существует несколько возможных эквивалентных представлений, при простом построчном сравнении эквивалентные строки могут быть признаны как неэквивалентные. Для решения этой проблемы в Unicode определяется несколько способов нормализации строк до их обработки. В XML 1.1 предусмотрено, что процессор XML 1.1 может проверить, находится документ в обычной форме или нет; в случае отсутствия такой информации, разработчикам приложений возможно придется выполнить нормализацию или убедиться, что их код не опирается на специфическую форму текста.

Почему появление XML 1.1 прошло незамеченным

Так почему о XML 1.1 так мало пишут? Если кратко - чтобы избежать хаоса. Успех XML во многом объясняется стабильностью и универсальностью этого языка. Можно быть уверенным, что любой процессор XML 1.0 сможет обработать данные в корректно-оформленном XML-документе. Появление новой версии XML по существу подобно введению нового формата - оно чревато одновременным существованием двух групп процессоров: 1.0 и 1.1. Даже если процессоры XML 1.1 поддержат 1.0 (и, следовательно, будут понимать и документы XML 1.0, и XML 1.1), огромное число существующих инструментов 1.0 "сломаются" на документах XML 1.1. Именно по этой причине необходимо, чтобы XML 1.1 вводился с осторожностью. Поэтому консорциум W3C рекомендует приложениям, которые применяются для создания XML-документов, продолжить максимально возможно использовать XML 1.0, и XML 1.1 - только в случае необходимости. На практике это означает, что если нет причин что-то менять, то ничего менять не следует. Этим объясняет почему большинство людей еще не видело XML 1.1. И хотя инструменты, подобные Xerces поддерживают XML 1.1 уже несколько месяцев, очень не многие это заметили. Благодаря такому подходу при внедрении процессоров XML 1.1 исключается возможность возникновения путаницы, что губительно для всей компьютерной отрасли.

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

Однако, даже в этом случае необходимо быть готовым к одной особой ситуации. Выше уже говорилось об обратной совместимости и совместимости снизу вверх - однако, к сожалению, XML 1.1 не полностью совместим с XML 1.0 снизу вверх. Дело в том, что несколько символов XML 1.0 недопустимы в XML 1.1 - это символы управления в диапазоне от #x7F до #x9F, которые, чтобы улучшить надежность определения кодировки символов, теперь должны появляться как ссылки на символы. Это требование может показаться странным в версии, которая призвана обеспечить возможность присутствия большего числа символов непосредственно в XML-документе, однако преимущества с точки зрения определения кодировки перевесили эту несогласованность и оказались достаточно значимыми, чтобы оправдать эту небольшую несовместимость. На практике это по-прежнему означает, что при генерации XML-документов 1.1 необходимо отыскать эти символы в данных.

Совместное использование внешних сущностей в документах 1.0 и 1.1

По мере создания XML-документов 1.1, все больше и больше людей захотят использовать внешние сущности и в документах XML 1.0, и XML 1.1. Как известно, одна из особенностей XML заключается в том, содержание может быть повторно использовано - для этого оно может сохранено в отдельных файлах, которые затем могут быть включены в один в другой. Такие части XML называются внешними сущностями (external entities). С появлением XML 1.1 возник вопрос о том, как обрабатывать эти сущности в смешанной среде, т.е. когда сущности XML 1.0 включены в документы XML 1.1. Для простоты в спецификации XML 1.1 говорится о том, что сущности обрабатываются согласно документу, в котором они используются. На практике это означает, что можно использовать старые сущности XML 1.0 в новых документах XML 1.1; чтобы они были помечены как XML 1.1, их не нужно конвертировать или дублировать. Единственная возможная проблема заключается в том, что если добавить один единственный символ XML 1.1 в сущность XML 1.0, процессор не определит это и будет ее обрабатывать как входные данные в XML 1.1. Тем не менее, это единственная проблема, если впоследствии попытаться использовать эту сущность как часть документа XML 1.0.

Спецификация "Пространства имен в XML 1.1"

Одновременно со спецификацией XML 1.1 W3C выпустил спецификацию "Пространства имен в XML 1.1". Новая версия спецификации претерпела минимальное число изменений. По большей части основная причина появления этой редакции заключается в том, что спецификация "Пространства имен в XML 1.0" - в соответствии с тем как она определена - ограничивается XML 1.0, и не может, строго говоря, использоваться с XML 1.1. В новой версии решается не только эта проблема - в ней также определена новая функциональность, о которой стоит упомянуть. Нверное многие задавались вопросом: почему допустимо не объявлять пространства имен по умолчанию, но не разрешается не объявлять определенный префикс? Это решение, принятое проектировщиками первой спецификации XML, оказалось для многих очень неудобным. Действительно, модель оказывается нерегулярной, и это отражается в спецификации Infoset. В новой версии спецификации "Пространства имен в XML 1.1" для устранения этого недостатка предлагается очевидной решение - префикс можно не объявлять, ассоциировав его с пустым пространством имен, например: xmlns:foo="".

Спецификации Infoset и версия 1.1

Характер изменений, появившихся в спецификации XML 1.1 и "Пространства имен в XML 1.1", не потребовал внесения соответствующих изменений в спецификации Infoset. Опубликовав две первые рекомендации, консорциум W3C также выпустил новую редакции спецификации XML Information Set, в которой описывается влияние этих двух спецификаций, но по существу эта редакция ограничивается описанием контента, который можно найти в Infoset. Модель данных не претерпела структурных изменений, и, следовательно, нет необходимости определять новые информационные единицы или модифицировать существующие. Это означает, что разработчикам не нужно озадачиваться этим вопросом: если в программах уже обрабатываются символы Unicode, значит можно обрабатывать новые символы, появившиеся в XML 1.1, ничего не изменяя.

Что еще предстоит сделать

Несмотря на то, что спецификация Infoset не требует внесения изменений, сказанное, к сожалению, не является справедливым в отношении всех других связанных с XML спецификаций. Например, необходимо пересмотреть спецификацию XML Schema. Действительно, тип xml:string, например, определяется на основе символов, допустимых в XML 1.0. Таким образом, на допустимость не будут проверяться строки, которые содержат символы управления XML 1.1. Это означает, что на самом деле XML-схема не может быть использована для проверки документов XML 1.1. Если используются только символы XML 1.1, процессор совместимый с XML-схемой, объявит такой документ недопустимым. Пока неизвестно, как будет решаться эта проблема, однако консорциум знает о ней и занимается ее изучением.

Заключение

Автор надеется, что эта статья снимет "покрывало таинственности", окружающее спецификации XML 1.1 и "Пространства имен в XML 1.1". Этот материал поможет читателю обрабатывать XML 1.1, если от него потребуют поддержать эту версию языка в своих программах. XML 1.1 не является революционной версией - это всего лишь эволюционная версия XML, которая не привносит кардинальных изменений. Большинство людей перейдут на процессоры XML 1.1 после модернизации своих парсеров точно так, как это сделали пользователи Xerces. На самом деле с момента появления версии 2.3.0 Xerces Java может разбирать XML-документы 1.1. А после недавнего выхода 2.5.0 Xerces C++ располагает аналогичными возможностями. Поэтому, читатель может быть даже и не зная об этом, уже выбрал одну из этих или более свежую версию и уже может обрабатывать документы XML 1.1.

Поддержка Unicode в программах

В технологии Java класс String может содержать любой символ Unicode, поэтому поддержка Unicode - всегда доступна. Однако, интерфейс прикладного программирования (API), предоставляемый инструментальным комплектом поддержки разработок (JDK) довольно ограничен, если речь заходит о обработке символов Unicode. По этой причине стоит подумать об использовании международных компонент для Unicode (International Components for Unicode или ICU; см. Ресурсы), которые также существуют для разработчиков C и C++ и содержат набор библиотек для поддержки Unicode, локализации и глобализации программного обеспечения.

Ресурсы

Об авторе

Арнод Ле Хорс (Arnaud Le Hors) - главный инженер отдела программного обеспечения корпорации IBM, он занимается разработкой стандартов ПО, связанных с стратегией компаний IBM "On Demand" (По требованию). Он представляет IBM в различных hабочих группах W3C: XML Core и DOM. Арнод Ле Хорс является редактором нескольких спецификаций, в том числе XML 1.1 и "Пространства имен в XML 1.1"

Оригинальный текст статьи можно посмотреть здесь:
XML 1.1 and Namespaces 1.1 revealed

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...