Использование возможностей абстрактных отношений Infoset

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

Листинг 1. Обнаружение complexType

// Find type definitions: for our purposes, the simplest // way to get all complexTypes is to drop down to the // underlying EMF model of a schema to iterate through // all concrete components contained within this schema // (Поиск определения типа: в нашем примере самый простой // способ получить все complexTypes опуститься к // базовой EMF-модели схемы, чтобы пройтись по всем // конкретным компонентам, находящимся в ней) List complexTypeDefinitions = new ArrayList(); for (Iterator iter = schema.eAllContents(); iter.hasNext(); ) { XSDConcreteComponent concreteComponent = (XSDConcreteComponent)iter.next(); if (concreteComponent instanceof XSDComplexTypeDefinition) { complexTypeDefinitions.add(concreteComponent); } } // An alternate method would be to use the abstract Infoset // relationship of schema.getTypeDefinitions(), which would // get all globally-visible typedefs (simple and complex) // within the whole schema, however that would miss any // types that were nested inside of other components // (Альтернативный способ - воспользоваться абстрактным // Infoset-отношением schema.getTypeDefinitions(), который // нашел все глобально видимые определения типов (простых и сложных) // во всей схеме, но тогда все вложенные в другие компоненты типы // остались бы незамеченными)

Теперь, когда у нас есть список всех complexType, которые необходимо скорректировать, давайте исключим любые типы, которые несовместимы с рассматриваемой программой. Поскольку мы просто запрашиваем информацию о различных компонентах схемы, можно воспользоваться многими абстрактными отношениями Infoset и методами, которые предлагает Модель. Эти абстрактные методы автоматически учитывают такие понятия, как базовые и производные типы, ссылки на объявления, находящиеся где-нибудь в другом месте, а также действие импортированных, включенных или переопределенных документов схемы.

Листинг 2. Поиск случаев несовместимости

// Detect name collisions between top-level elems and attrs // ( Обнаруживает конфликт имен между высокоуровневыми // элементами и атрибутами) List elementNames = getElementNames(complexType); List attributeNames = getAttributeNames(complexType); attributeNames.retainAll(elementNames); if (!attributeNames.isEmpty()) { // Report the name collision and return... // (Сообщает о конфликте имен и возвращает...) }

// Now check for any attribute wildcards, which we // can't really change into elements // (Проверяет групповые символы, которые нельзя // превратить в элементы) XSDWildcard attributeWildcard = complexType.getAttributeWildcard(); if (null != attributeWildcard) { // Report an incompatible wildcard and return... // (Сообщает о несовместимых групповых символах имен и возвращает...) }

// Check the content for other incompatible conditions like // groups with choice or all or a simpleType // (Проверяет содержание на другие несовместимые условия, как // группы с выбором или все или simpleType) XSDComplexTypeContent complexTypeContent = complexType.getContent(); if (complexTypeContent instanceof XSDSimpleTypeDefinition) { // Report a simple type as incompatible and return... // (Сообщает о несовместимых простых типах и возвращает...) } else if (null != complexTypeContent) { XSDTerm particleTerm = ((XSDParticle)complexTypeContent).getTerm();

if (particleTerm instanceof XSDModelGroup) { XSDCompositor compositor = ((XSDModelGroup)particleTerm).getCompositor(); if ((XSDCompositor.ALL_LITERAL == compositor) (XSDCompositor.CHOICE_LITERAL == compositor)) { // Report an incompatible group type and return... // (Сообщает о несовместимых типах групп и возвращает...) } } // more checks for wildcards, etc. // (еще проверки групповых символов и т.д.) }

Примечание. В этом примере приведен не весь код, используемый для обнаружения случаев несовместимости; пожалуйста, скачайте zip-файл с примерами (см. ), чтобы увидеть его целиком. Программа MakeSoapCompatible.java тщательно спроектирована, в ней приводятся подробные комментарии, указывающие, как манипулировать схемами с помощью этой Модели. Их изучение является необходимым условием, если вы хотите углубиться свои знания.

Код примера

Пример кода, рассматриваемый в этой статье, демонстрируется с помощью программы MakeSoapCompatible.java, интересующиеся могут изучить комментарии, содержащиеся в полном коде. К программе прилагается документ простой схемы MakeSoapCompatible.xsd, который показывает базовую форму заказа на покупку, в которой необходимо заменить атрибуты на элементы. Указанную программу также можно применять для работы с другими документами схем. Чтобы программа могла работать автономно необходимо наличие Модели XSD Schema Infoset и оболочки моделирования Eclipse

Эту программу и программы-утилиты можно скачать в виде одного zip-файла (см. ).

Копии двух других java-файлов утилит, обычно поставляемых вместе с Моделью XSD Schema Infoset (версии 1.0.1 и выше), содержатся в коде с комментариями. Эти утилиты позволяют реализовать некоторые другие полезные технологии, а именно:

XSDSchemaQueryTools.java демонстрирует несколько других способов выполнения сложных запросов к компонентам схемы.

XSDSchemaBuildingTools.java содержит удобные методы программного построения схем.

Конкретизация при добавлении компонентов и манипулировании ими

После того, как вы обнаружили некоторые complexType, которые требуется скорректировать, необходимо провести конкретизацию. Для каждого complexType следует пройтись по списку getAttributeContents(), который показывает, какие конкретно атрибуты использует этот тип. Для каждого случая использования сначала убедитесь, что вы указываете на фактическое объявление атрибута - даже если это ссылка на объявление, находящиеся где-то в другом месте. В этом случае важно создать elementDeclaration, который имеет те же имя и тип, что и в каждом случае использования атрибута - это довольно простой процесс. Кроме того, необходимо поместить elementDeclaration внутрь getContents() новой единицы, поскольку эта единица позже будет добавлена в complexType.

Листинг 3. Замена атрибутов элементами

if (attrDecl.isAttributeDeclarationReference()) attrDecl = attrDecl.getResolvedAttributeDeclaration();

// Create a blank element and simply copy over the // pertinent data about the attribute // (Создает пустой элемент и просто копирует // соответствующие данные о атрибуте XSDElementDeclaration elemDecl = XSDFactory.eINSTANCE.createXSDElementDeclaration(); elemDecl.setName(attrDecl.getName()); elemDecl.setTypeDefinition(attrType);

// Note that since an annotation's elements are only modeled // in the concrete tree that we must explicitly ask to clone them // (Внимание: т.к. элементы аннотации моделируются только в // конкретном дереве, необходимо явно потребовать клонировать их) if (null != attrDecl.getAnnotation()) { cloneAnnotation(attrDecl, elemDecl); } // Wrap this element in a particle // (Обернуть этот элемент в едницу) XSDParticle particle = XSDFactory.eINSTANCE.createXSDParticle(); particle.setContent(elemDecl);

Это именно та область, которая четко показывает различие между конкретной и абстрактной моделями. Возможно, вам станет любопытно, что же это за единица, если при просмотра файлов schemaDocument.xsd, вы не видите никаких элементов xsd:particle. Для этого прочтите спецификацию для единиц (), хотя она довольно обширна. Единица, в сущности, это абстрактный контейнер объявления имен, группы моделей или чего бы то ни было (группового символа); единица - это то, что определяет свои ограничения min/maxOccurs в отдельном месте в схеме. Поскольку Модель может выражать и конкретные, и абстрактные представления схемы, несложно работать с любым видом представления.

Аннотации - это единственный вид компонента схемы, которые моделируются только в конкретном представлении модели, и поэтому они требуют несколько особенной обработки. В этом примере кода любые аннотации копируются из объявления атрибута в новое, только что созданное, объявление элемента. В действительности, чтобы клонировать или копировать содержимое компонента аннотации, необходимо использовать метод DOM cloneNode(), а затем добавить саму аннотацию в новое объявление элемента.

Листинг 4. Клонирование конкретных аннотаций

XSDAnnotation oldAnnotation = attrDecl.getAnnotation(); XSDAnnotation newAnnotation = XSDFactory.eINSTANCE.createXSDAnnotation(); try { Element oldAnnElem = oldAnnotation.getElement(); // Use the DOM method to do a deep clone of the element Element newAnnElem = (Element)oldAnnElem.cloneNode(true); newAnnotation.setElement(newAnnElem); elemDecl.setAnnotation(newAnnotation); } catch (Exception e) { // Report the error and return // (Сообщает об ошибке и возвращается) }

Корректирование XML-схем: получение схем, удобных для SOAP

Во все большем числе проектов используются XM-схемы для определения структуры данных. По мере роста репозитория схем, становится очевидной потребность в инструментальных средствах, предназначенных для манипулирования и управления схемами. Модель Eclipse XSD Schema Infoset обладает широкими возможностями построения запросов и редактирования. Автор статьи Шейн Куркуру рассказывает о том, как можно модернизировать схему для ее использования с SOAP с помощью автоматического преобразования определений используемых атрибутов в определения элементов.

Предполагается, что читатель знаком с XML-схемами и понимаете, как функционирует SOAP. Код примеров, содержащийся в , может работать как автономно, так и в инструментальном средстве Eclipse.

Краткое изложение применяемого подхода

Если вы вспомните о сложной структуре XML-схем, вы вряд ли захотите воспользоваться Notepad, чтобы редактировать xsd-файлы. Любой хороший XML-редактор не на много лучше - несмотря на то, что он, возможно, отлично организовывает элементы и атрибуты, он не может показывать многочисленные абстрактные отношения Infoset, которые определены в спецификации Schema. Именно здесь на выручку приходит Модель Schema Infoset: она выражает и конкретное DOM-представление набора документов схемы, и полную абстрактную Infoset-модель схемы. Оба эти представления демонстрируются с помощью программного API Модели, а также встроенного редактора схем.

Переписывание схемы

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

Предполагается, что по крайней мере, некоторые объявления атрибутов были преобразованы в эквивалентные объявления элементов. В этом случае важно сохранить эту схему для дальнейшего использования с SOAP-приложением. Оболочка EMF, на которой построена эта Модель, обеспечивает сервисы обработки ресурсов, которые различны способами загружают и сохраняют документы схемы. Код примера демонстрирует очень простой способ сериализации непосредственно в универсальный идентификатор ресурса (URI), в этом случае выходной файл на диске называется по имени оригинального входного файла.

Листинг 6. Запись схемы в файл

File outFile = new File(newLocation); FileOutputStream fos = new FileOutputStream(outFile); // Ensure that the abstract model is synchronized with the // concrete tree: this will ensure that the Model has // updated the concrete Element in the schema document // with any changes that may have been made in the // abstract model // (Убедитесь, что абстрактная модель синхронизирована с // конкретным деревом: это гарантирует, что Модель обновила // конкретный элемент в документе схемы с учетом всех изменений, // внесенных в абстрактную модель) schema.updateElement();

// Simply ask the XSDResourceImpl to serialize the schema to // a document for us; this is just one way we can easily use // the XSD/EMF framework to manage resources for us // (Просто запрашивает XSDResourceImpl сериализовать схему // в документ; это просто способ использования оболочки // XSD/EMF для управления ресурсами) XSDResourceImpl.serialize(fos, schema.getElement()); fos.close();

"Подчистите" свою схему для SOAP

Автор: Шейн Куркуру (Shane Curcuru)

Перевод:

Авторские права:

Ресурсы

Скачайте код примера в виде .

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

Прочитайте предыдущую статью Шейна Куркуру "Анализ XML-схем с помощью Модели XSD Schema Infoset" (, developerWorks, июнь, 2002 год).

Изучите все о "".

Посмотрите Примечание "" или узнайте планы Рабочей группы XML-протокола () консорциума W3C касательно SOAP.

Познакомьтесь со статьей Билала Сиддикуи (Bilal Siddiqui') "Развертывание Web-сервисов с помощью языка WSDL, часть 2: Простой протокол доступа к объектам (SOAP)" (, developerWorks, март, 2002 год).

Прочитайте о вопросах проектирования в XML-форматах () - что выбрать элементы или атрибуты - статью Дэвида Мертца (David Mertz) "" (Tip: Subelement contents versus tag attributes, developerWorks, ноябрь, 2001 год).

Задавайте технические вопросы о Модели XSD () в конференции.

Визуальное редактирование схемы

Если вы установили Модель XSD Schema Infoset и дополнения к Оболочке моделирования Eclipse (EMF) в Eclipse, вы можете узнать, как работает этот редактор в инструментальном средстве. (Примечание: данная статья не подразумевает обязательного изучения этого редактора). Просто щелкните правой кнопкой мышки по файлу schema.xsd в меню Navigator и выберите Open With... а затем Sample XML Schema Editor. Вы откроете стандартный редактор Eclipse, который показывает обычное окно Source - это конкретное DOM-представление xsd-файла, который вы открыли.

В нижней части редактора находятся еще две закладки: Semantics и Syntax. Это графические представления, демонстрирующие различные абстрактные отношения Infoset между компонентами схемы. Например, в окне Semantics можно увидеть высокоуровневый элемент для Types - это все типы (простые и сложные), объявленные где угодно в самой схеме, а не только на верхнем уровне и не просто в этом документе (эта функциональность становится более очевидной, если открытый вами документ схемы использует элементы include и import).

В рамках рассматриваемого примера немного упростим изучаемую проблему. MakeSoapCompatible.java - это программа, которая попытается взять большинство attributeDeclarations и превратить их в приблизительные эквиваленты attributeDeclaration, выдав несколько предупреждений.

В первую очередь отметим, что невозможно преобразовать атрибут в элемент, если уже существует элемент с таким именем в единицах (particle) complexType. Следовательно, сначала установим случаи конфликта имен и не станем эти атрибуты. Чтобы упростить пример, объявим некоторые произвольные условия, чтобы схема была несовместима с этой программой. Не будем изменять схемы, которые содержат групповые символы, поскольку в этом случае потребовалось бы выполнять сложную проверку имен, чтобы убедиться, что ни один из измененных атрибутов не конфликтует с элементами. Также не будем модифицировать группы, которые в качестве компоновщика используют #all или #choice, так как это непредсказуемым способом могло бы изменить значение группы.

пример очистки XML-документа

Если вы создали библиотеку схем, возможно, вам захотите воспользоваться ею в новых проектов. Например, если вы уже применяете модель данных для внутренней формы заказа на поставку, то при переходе к использованию Web-сервисов может появиться необходимость модернизировать ее для работы с SOAP. SOAP позволяет передавать XML-сообщение по сети; с помощью схемы на xml body можно накладывать ограничения. Однако, для своего элемента xml body SOAP, как правило, использует данные элементов, а не атрибутов. Рассмотрим программу, которая может автоматически скорректировать существующий документ схемы, преобразов любое объявление атрибута в приблизительно "эквивалентные" объявления элементов.

Рис.1. Преобразование атрибутов в элементы

Как было показано выше, выполнение умозрительно простой операции редактирования документовхем (преобразования атрибутов в элементы) может повлечь за собой достаточно много работы. Однако, эта задача становится управляемой благодаря возможности представления Моделью Schema Infoset и абстрактного Infoset схемы, и ее конкретного представления документов схемы. Эта Модель также содержит простые инструментальные средства для загрузки и сохранения документов схемы в различные источники, позволяя программно управлять репозиторием схем.
Некоторые пользователи могут задаться вопросом: "А почему бы не воспользоваться XSLT или другим XML-приложением для редактирования документов схемы?" Несмотря на то, что XSLT может легко обрабатывать конкретную модель набора документов схем, эта технология просто не может увидеть любое абстрактное отношение во всей схеме, которую эти отношения представляют. Предположим, например, что необходимо обновить какие-нибудь перечисляемые simpleType, чтобы добавить новую перечисляемую величину UNK, которая неизвестно что значит. Разумеется, вы просто хотите скорректировать перечисления, которые соответствуют формату, при котором используются строки длиной три символа, и вам не нужно исправлять числовые или иные перечисления.
Несмотря на то, что технология XSLT могла бы найти все объявления simpleType, она не может понять отношения между типами и базовыми типами или просто вычислить значения фасетов в этих типах. Модельное представление абстрактных отношений Infoset в схеме включает нечто, как simpleType.getEffectiveEnumerationFacets(), что учитывает базовые типы, ссылки и другие отношения в схеме. Этот метод возвращает полный список перечислений в этом simpleType, к которому можно обращаться с запросом и который, если это необходимо, можно скорректировать новыми величинами. Модель также позволяет включать поддержку управления пространствами имен и разрешать другие типы в любой точке схемы, что было бы сложно сделать при помощи прочих инструментальных средств.

Замена атрибутов элементами

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

Листинг 5. Использование конкретных списков для удаления атрибутов

// Use this concrete relationship, since we're going to // actually remove the attributes from this type // (Использует это конкретное отношение, т.к. из этого // типа будут удаляться атрибуты) for (ListIterator iter = complexType.getAttributeContents().listIterator(); iter.hasNext(); /* no-op */ ) {

if (changeAttributeIntoElement(complexType, (XSDAttributeGroupContent)iter.next(), changedAttrs)) { // Note that list manipulation calls like remove() // will only work properly on concrete lists; // attempting to manipulate 'abstract' lists will // either throw an exception or will silently fail // (Внимание: вызовы манипуляции списком, как remove() // будет работать корректно только на конкретных // списках; попытка манипулировать "абстрактными" // списками, либо сгенерирует исключение, либо приведет к сбою) iter.remove(); } else { // Report the error and continue... // (Сообщает об ошибке и продолжает...) } }

Фрагмент кода разработанной таксономии

<?xml version="1.0" encoding="windows-1251"?>




<schema targetNamespace="urn:stp:stp-f102:1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:xbrli="http://www.xbrl.org/2001/instance"
        xmlns:link="http://www.xbrl.org/2001/XLink/xbrllinkbase"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        xmlns:xhtml="http://www.w3.org/1999/xhtml"
        xmlns:stp-f102="urn:stp:stp-f102:1.0" elementFormDefault="qualified">

<import namespace="http://www.xbrl.org/2001/instance"
        schemaLocation="http://www.xbrl.org/2001/xbrl-instance.xsd"/>



        <element id="stp-f102_ОтчетПрибыляхУбытках"
                 name="ОтчетПрибыляхУбытках" abstract="true"/>
        <element id="stp-f102_Доходы"
                 name="Доходы" abstract="true"/>
        <element id="stp-f102_ВсегоДоходов_10000.СуммыОтОперацийРублях"
                 name="ВсегоДоходов_10000.СуммыОтОперацийРублях"
                 type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"/>

        <element id="stp-f102_НегосударственнымФинансовымОрганизациям_11111.СуммыОтОперацийРублях"
                 name="НегосударственнымФинансовымОрганизациям_11111.СуммыОтОперацийРублях"
                 type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"/>
        <element id="stp-f102_НегосударственнымКоммерческимОрганизациям_11112.СуммыОтОперацийРублях"
                 name="НегосударственнымКоммерческимОрганизациям_11112.СуммыОтОперацийРублях"
                 type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"/>
        <element id="stp-f102_НегосударственнымНекоммерческимОрганизациям_11113.СуммыОтОперацийРублях"
                 name="НегосударственнымНекоммерческимОрганизациям_11113.СуммыОтОперацийРублях"
                 type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"/>
        <element id="stp-f102_ИндивидуальнымПредпринимателям_11114.СуммыОтОперацийРублях"
                 name="ИндивидуальнымПредпринимателям_11114.СуммыОтОперацийРублях"
                 type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"/>
        <element id="stp-f102_Гражданам_ФизическимЛицам_11115.СуммыОтОперацийРублях"
                 name="Гражданам_ФизическимЛицам_11115.СуммыОтОперацийРублях"
                 type="xbrli:monetaryItemType" substitutionGroup="xbrli:item"/>

        <element id="stp-f102_НормативныйИсточник"
                 name="НормативныйИсточник" type="string" substitutionGroup="link:part"/>
</schema>

Фрагмент кода реального документа

<?xml version="1.0" encoding="windows-1251"?>





<group xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="http://www.xbrl.org/2001/instance"
       xsi:schemaLocation="urn:stp:stp-f102:1.0 stp-f102-v2.xsd"
       xmlns:stp-f102="urn:stp:stp-f102:1.0">



       <stp-f102:ВсегоДоходов_10000.СуммыОтОперацийРублях
                 numericContext="Year2002">
                         2048767
       </stp-f102:ВсегоДоходов_10000.СуммыОтОперацийРублях>

       <stp-f102:НегосударственнымФинансовымОрганизациям_11111.СуммыОтОперацийРублях
                 numericContext="Year2002">
                         113
       </stp-f102:НегосударственнымФинансовымОрганизациям_11111.СуммыОтОперацийРублях>
       <stp-f102:НегосударственнымКоммерческимОрганизациям_11112.СуммыОтОперацийРублях
                 numericContext="Year2002">
                         80431
       </stp-f102:НегосударственнымКоммерческимОрганизациям_11112.СуммыОтОперацийРублях>
       <stp-f102:НегосударственнымНекоммерческимОрганизациям_11113.СуммыОтОперацийРублях
                 numericContext="Year2002">
                         735
       </stp-f102:НегосударственнымНекоммерческимОрганизациям_11113.СуммыОтОперацийРублях>
       <stp-f102:ИндивидуальнымПредпринимателям_11114.СуммыОтОперацийРублях
                 numericContext="Year2002">
                         2374
       </stp-f102:ИндивидуальнымПредпринимателям_11114.СуммыОтОперацийРублях>
       <stp-f102:Гражданам_ФизическимЛицам_11115.СуммыОтОперацийРублях
                 numericContext="Year2002">
                         19518
       </stp-f102:Гражданам_ФизическимЛицам_11115.СуммыОтОперацийРублях>

       <numericContext cwa="true" id="Year2002" precision="18">
            <entity>
                 <identifier scheme="http://www.somebank.ru">Банк</identifier>
            </entity>
            <period>
                 <instant>2003-01-01</instant>
            </period>
            <unit>
                 <measure>RUB</measure>
            </unit>
       </numericContext>
</group>

Некоммерческое партнерство "Стандарты

Дата: 15-08-2003
Подготовлено: по материалам компании Intersoft Lab

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

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

С целью решения этой и других задач в январе 2002 года было создано Некоммерческое партнерство "Стандарты электронного обмена информацией" (далее - Партнерство), в состав которого вошли представители ведущих отечественных производителей программного обеспечения и финансовых организаций: АОЗТ "1С Акционерное общество", ЗАО "Банковские Информационные системы", Московское представительство "Microsoft", Представительство фирмы "Intel", ЗАО Парус, ООО "Intersoft Lab", ЗАО "Центр финансовых технологий", ЗАО "Эр-Стайл Софтлаб", ЗАО "Диасофт", Акционерный коммерческий Сберегательный Банк Российской Федерации, Ассоциация российских банков, Российская Национальная ассоциация Членов СВИФТ.

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

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

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

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

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

"Формально"

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

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

Инициатором такого предложения может выступать Совет директоров, Исполнительная дирекция, Комитет (Подкомитет), либо член Партнерства.

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

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

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

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

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

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

Наконец, потребовалось провести анализ существующих языков описания структуры и форматов данных, а также существующих стандартов с целью выявления наиболее подходящих для решения данной задачи. Так, определение расширяемого языка разметки XML в качестве языка описания формата означает упрощение существующих процессов взаимодействия с другими системами и передачи данных по различным протоколам. Выбор же Международного стандарта XBRL (eXtensible Business Reporting Language, Расширяемый язык бизнес-репортинга) в качестве начального стандарта позволяет воспользоваться мировым опытом в области разработки стандартов электронного обмена данными, а также создает предпосылки для взаимодействия с иностранными партнерами при обмене финансовой информацией.

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

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

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

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

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

Рис. 1.

Следующим шагом стало построение словаря (таксономии), описывающего данные предметной области на языке описания формата (языке XML). Данная таксономия является документом-схемой, которая отвечает требованиям Рекомендации W3C Schema (XML Schema Part 1: Structures и XML Schema Part 2: Datatypes), а также Рекомендации XBRL 2.0a (Specification XRBL 2.0a) - начального стандарта (см. фрагмент кода разработанной таксономии).
На данном этапе также был выполнен анализ рынка программных продуктов, предназначенных для создания таксономий. Причиной проведения данного исследования является необходимость автоматизации процесса формирования таксономии - "ручное" создание таких словарей представляет собой весьма трудоемкую задачу, кроме того, в этом случае элиминируется сама идея автоматизации. В результате, было выявлено наличие нескольких как коммерческих версий таких продуктов, различающихся прежде всего надежностью предоставляемых функциональных возможностей, так и бесплатных приложений, но представленных в виде альфа-версий (либо поддерживающих предыдущую Рекомендация XRBL - Specification XRBL 1.0).
После проведенного сравнительного анализа имеющихся программных средств было принято решение создать собственное решение, которое наиболее подходило бы поставленной задаче. С этой целью разработчики компании Intersoft Lab написали скрипт на языке программирования Python, который позволял выполнять генерацию схемы таксономии и баз связей.

Для того, чтобы разработанная таксономия не превратилась в документ "в самом себе", был подготовлен пример отчета (для 101-о1 и 102-й форм), реализованного в виде xml-файла (реального документа), который был сформированного с помощью имен (финансовых фактов), описанных в таксономии. Этот пример реального документа является иллюстрацией формата, в котором предлагается публиковать финансовую отчетность (см. фрагмент кода реального документа).

Необходимо отметить, что подобная практика широко применяется международными органами стандартизации. Так, в состав пакета таксономии "Primary Financial Statements (PFS, Основные финансовые отчеты), Financial Reporting for Commercial and Industrial Entities (Финансовая отчетность для коммерческих и промышленных организаций), International Accounting Standards (IAS, Международные стандарты финансовой отчетности)", о которой мы подробно писали в нескольких номерах Журнала (см. Журнал №, № и №) включен xml-файл примера финансовых отчетов некоторой вымышленной компании.

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

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

В настоящий момент проект "Стандарта публикации финансовой отчетности коммерческих банков" находится на рассмотрении Подкомитета по финансовой отчетности - по нему ведется переписка, осуществляется обмен мнениями, принимаются предложения.

document.write('');

Новости мира IT:

02.08 - 02.08 - 02.08 - 02.08 - 02.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 31.07 - 31.07 - 31.07 - 31.07 - 31.07 -

Архив новостей

Последние комментарии:

(66)

2 Август, 17:53

(19)

2 Август, 17:51

(34)

2 Август, 15:40

(42)

2 Август, 15:35

(1)

2 Август, 14:54

(3)

2 Август, 14:34

(3)

2 Август, 14:15

(2)

2 Август, 13:34

(7)

2 Август, 13:04

(3)

2 Август, 12:28

BrainBoard.ru

Море работы для программистов, сисадминов, вебмастеров.

Иди и выбирай!

Loading

google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true);

IT-консалтинг

Software Engineering

Программирование

СУБД

Безопасность

Internet

Сети

Операционные системы

Hardware

PR-акции, размещение рекламы — ,
тел. +7 495 6608306, ICQ 232284597

Пресс-релизы —

This Web server launched on February 24, 1997

Copyright © 1997-2000 CIT, © 2001-2009

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

CSS

Вспецификации «Каскадные таблицы стилей» (Cascading Style Sheets (CSS)) [Рекомендация W3C] описывается, как применять стиль презентации к разметке. Эта спецификация широко известна благодаря своему использованию при форматировании HTML Web-страниц, однако после выхода CSS Level 2 она стала подходить и для представления XML-документов в среде Web. Преобразование XML-документов в выходную структуру осуществляется с помощью свойства display. В спецификации «Ассоциирование таблиц стилей с XML-документами, версия 1.0» (Associating Style Sheets with XML documents, Version 1.0) [Рекомендация W3C] определен стандартный способ связывания XML-документа с документом таблицы стилей CSS.

DOM

Вспецификации «Объектная модель документов» (Document Object Model (DOM)) [Рекомендация W3C] описывается объектная модель XML-документов, которая может быть использована для прямого доступа к частям XML-документа. Согласно концепции модели DOM, документ моделируется в виде дерева, в котором каждый компонент синтаксиса XML (как, например, элемент или текстовое содержание) представляется с помощью узла.

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

Модель DOM задумывалась как нейтральная от языка. Для выражения узлов DOM и поддержки интерфейсов используется спецификация консорциума по технологии манипулирования объектами (Object Management Group, OMG) «Язык описания интерфейса CORBA» (CORBA Interface Definition Language (IDL)) [Международный стандарт ISO, номер 14750].

Первоначально модель DOM создавалась как объектная модель для стандартизации криптовых операций над объектами HTML и XML в Web-браузерах. В некоторых случаях это приводит к затруднениям при использовании этой модели в качестве изолированного интерфейса прикладного программирования. При разработке модели DOM выпускалось несколько версий спецификации (Level), каждая из которых опирается на предыдущую, добавляя новые функциональные возможности.

Так, документ Level 1 охватывал основные возможности, в Level 2 появилась поддержка пространств имен, модель событий пользовательского интерфейса, итераторы и многое другое. В Level 3 включены интерфейсы прикладного программирования для загрузки в файлы XML-документов и сохранения из них, для интегрирования XPath, поддержка проверки допустимости и другое.

Хотя в целом овладеть DOM гораздо легче, чем SAX, поскольку в модели DOM не задействованы функции обратного вызова и сложное управление состоянием, реализации DOM обычно хранят все узлы XML в памяти, что может быть весьма неэффективно для больших документов. Несмотря на то, что реализации DOM написаны на многих языках, модель DOM задумана как независимая от языка.

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

Языки программирования для XML

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

Технология Java: Страница alphaworks XML на сайте IBM (IBM alphaworks XML page); страница XML на сайте Apache (The Apache XML page); некоммерческая страница технологии Java и XML на сайте Sun (Sun's community page of Java Technology and XML)

C/C++: C/C++ developers: Fill your XML toolbox) (developerWorks, сентябрь 2001г.)

Python: Специальная группа, занимающаяся обработкой XML в Python (Special Interest Group for XML Processing in Python); колонка Python & XML на XML.com; The State of the Python-XML Art, 2003); сайт Юча Огбуджи Akara, посвященный обработке XML в Python (Uche Ogbuji's Akara site on XML processing in Python)

Perl: Perl developers: Fill your XML toolbox) (developerWorks, июнь 2001г.); проект Perl-XML (Perl-XML Project); колонка Perl & XML на XML.com; XMLperl.com.

Другие: Классы PHP XML (PHP XML Classes); <rubyXML/>; XML and Scheme.

Канонический XML («c14n»)

Вспецификации «Канонический XML, версия 1.0» (Canonical XML Version 1.0) [Рекомендация консорциума W3C] определяется стандартный метод генерации физического представления XML-документа, называемого канонической формой. В этой спецификации объясняется, как выполнять эти модификации, допустимые с точки зрения синтаксиса XML, не меняя при этом содержания. Например, порядок атрибутов в XML не имеет значения, поэтому, если в одном документе все атрибуты отсортированы в алфавитном порядке, а другой документ отличается от первого только тем, что атрибуты располагаются в каком-то ином порядке, эти два документа являются идентичными с точки зрения XML 1.0, несмотря на различия в физическом представлении. В результате, возникают серьезные практические проблемы. Например, в случае если необходимо поставить цифровую подпись на документ, чтобы гарантировать его целостность, изменение порядка атрибутов приводит к нарушению подписи, несмотря на то, что сам документ при этом не изменяется. Решение этой проблемы заключается в преобразовании документов в каноническую форму (процесс называемый «канонизацией c14n») до того, как будут выполняться различные операции над документом: его подписание, сравнение текста и т.п. Благодаря этому, изменения, не существенные с точки зрения XML 1.0, вносятся корректным образом.

Иногда, XML-документ, который необходимо сравнить или подписать, на самом деле является просто разделом более крупного документа. Спецификация c14n учитывает и этот случай — указывая порядок обработки конструкций XML, например, объявлений пространств имен. В том случае, если требуется, чтобы эта спецификация ограничивалась подмножеством документа, необходимо использовать соответствующий алгоритм «Исключающая канонизация XML, версия 1.0» (Exclusive XML Canonicalization Version 1.0) [Рекомендация консорциума W3C].

Каталоги

Вспецификации «Каталоги XML» (XML Catalogs) [спецификация комитета организации OASIS] описывается формат инструкций, которые определяют, как XML-процессор преобразует идентификаторы сущностей (entity) XML в фактические документы. Например, каталог сущностей (entity catalog) можно использовать для указания местоположения, с которого XML-процессор загружает DTD при наличии системных и открытых идентификаторов для этого DTD. Системные идентификаторы обычно задаются унифицированными идентификаторами ресурса (Uniform Resource Identifier, URI), которые регулируются документом «Запрос на комментарий 2396: Унифицированные идентификаторы ресурса» (RFC 2396: Uniform Resource Identifiers) [Запрос на комментарии Целевой группы инженерной поддержки Internet (IETF RFC)]. Унифицированный идентификатор ресурса — это всего лишь расширение унифицированного указателя информационного ресурса (Uniform Resource Locator, URL), который используется в Web-браузерах. Все унифицированные указатели ресурса — это унифицированные идентификаторы ресурса, но указатели также включают унифицированные имена ресурса (Uniform Resource Name, URN), которые регулируются документом «Запрос на комментарий 2141: Унифицированные имена ресурса» (RFC 2141: Uniform Resource Names) [Запрос на комментарии Целевой группы инженерной поддержки Internet], которые являются способом указания Web-ресурсов по имени, а не по местоположению (см. «Устав рабочей группы URN» («The URN Charter»)). Открытые идентификаторы обычно определяются как формальные открытые идентификаторы (Formal Public Identifiers, FPIs), которые определены на языке SGML. Каталоги также можно применять в ситуациях, когда используемая машина не располагает сетевым доступом к ресурсам, указанным унифицированным локатором, или когда организации требуется заменить внешний ресурс локальной версией.

Каталог XML является XML-документом, однако, имеется более ранний формат для SGML и XML, который определяет формат каталога в более простом виде — «Управление сущностями: Техническая резолюция OASIS 9401:1997» (Entity Management, OASIS Technical Resolution 9401:1997) [Стандарт организации OASIS]. Этот формат часто называют Открытым каталогом OASIS (OASIS Open Catalog).

Многообразие стандартов

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

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

Международная организация по стандартизации (International Organization for Standardization (ISO)), вероятно, наиболее авторитетный орган стандартизации в мире. Многие из отраслевых стандартов ISO равносильны законам.

Организация по стандартизации структурированной информации (Organization for the Advancement of Structured Information Standards (OASIS)) несколько изменилась со времен образования консорциума SGML, но результаты ее деятельности остались прежними. То, что ранее называлось Технические резолюции (Technical Resolutions), теперь известны как Спецификации комитетов (Committee Specifications), а их предназначение схоже с Рекомендациями W3C.

Целевая группа инженерной поддержки Internet (Internet Engineering Task Force (IETF)) представляет собой модель организации, которая пытается привлечь к работе над стандартами широкие массы, формально оставаясь при этом организацией. Практически любой человек, имеющий доступ в Интернет, может подать на рассмотрение Рабочий вариант Интернет-документа (Internet Draft) и предложить его в качестве возможного стандарта. Группа, регулирующая процесс стандартизации (steering group), изучает этот документ и может рекомендовать его публикацию в качестве Запроса на комментарий (Request for Comment, RFC). Запросы могут быть помечены как Запрос на комментарий, рекомендованный как опытный стандарт (Standards Track RFC), и даже как Запрос на комментарий, рекомендованный как стандарт (Standard RFC), хотя большинство публикаций, появившихся как Запрос на комментарий, пользуются большим авторитетом и часто широко применяется.

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

Обавторе

Юч Огбуджи (Uche Ogbuji) - консультант и один из основателей Fourthought, компании, занимающейся поставками программного обеспечения и предоставлением консалтинговых услуг в области XML-решений для корпоративного управления знаниями. Fourthought разрабатывает 4Suite, платформу с открытым исходным кодом, для XML, RDF и приложений по управлению знаниями. Юч Огбуджи - инженер в области вычислительной техники, он родился в Нигерии, сейчас живет и работает в Боулдер-Сити (Boulder), штат Колорадо, США. С ним можно связаться по адресу uche.ogbuji@fourthought.com.

Оригинальный текст статьи можно посмотреть здесь:
A survey of XML standards: Part 1

Обзор XML-стандартов, часть 1Базовые XML-стандарты- основа основ

Юч Огбуджи (Uche Ogbuji)

Перевод: Intesoft Lab

Мир XML огромен и постоянно растет, он населен множеством стандартов и технологий, которые связаны друг с другом самым причудливым образом. Поэтому тем, кто только начинает свое знакомство с XML, может оказаться непросто ориентироваться в наиболее важных аспектах XML, тем же, кто уже использует XML — следить за новинками и изменениями. Эта серия статей, подготовленных Ючем Огбуджи — учебное пособие по XML-стандартам, которое содержит множество справочных материалов.

С момента своего появления язык XML зарекомендовал себя с самой лучшей стороны, поэтому довольно быстро получил широкое распространение. Он оказался чрезвычайно полезной технологией, которая, однако, может оказаться весьма непростой для понимания — если попытаться рассмотреть все, что попадает под определение «XML». В этой серии статей автор кратко рассмотрит наиболее важные, по его мнению, XML-технологии и расскажет, какое место в мире XML занимает каждая из них. Кроме того, в конце каждого раздела, посвященного той или иной из обсуждаемых технологий, читатель сможет найти список рекомендуемых учебных пособий и других справочных материалов, которые могут оказаться полезными при ее изучении и апробировании.

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

Эта статья посвящена базовым XML-технологиям. Именно с помощью этих технологий выражаются XML-документы. В следующих статьях будут рассмотрены , а также ряд наиболее важных XML-приложений (или словарей).

Обзор XML-стандартов, часть 2Стандарты для обработки XML

Юч Огбуджи (Uche Ogbuji)

Перевод: Intesoft Lab

Мир XML огромен ипостоянно растет, он населен множеством стандартов и технологий, которые связаны друг с другом самым причудливым образом. Поэтому тем, кто только начинает свое знакомство с XML, может оказаться непросто ориентироваться в наиболее важных аспектах XML, тем же, кто уже использует XML —следить за новинками и изменениями. Автор этой серии статей, посвященной XML-стандартам, Юч Огбуджи на этот раз рассказывает о технологиях обработки XML.

С момента своего появления язык XML зарекомендовал себя с самой лучшей стороны, поэтому довольно быстро получил широкое распространение. Он оказался чрезвычайно полезной технологией, которая, однако, может оказаться весьма непростой для понимания —если попытаться рассмотреть все, что попадает под определение «XML». В этой серии статей автор кратко рассмотрит наиболее важные, по его мнению, XML-технологии и расскажет, какое место в мире XML занимает каждая из них. Кроме того, в конце каждого раздела, посвященного той или иной из обсуждаемых технологий, читатель сможет найти список рекомендуемых учебных пособий и других справочных материалов, которые могут оказаться полезными при ее изучении и апробировании.

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

Продолжение следует

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

Пространства имен

В спецификации «Пространства имен XML 1.0» (Namespaces inXML 1.0) [Рекомендация консорциума W3C] описывается механизм универсального обозначения имен элементов и атрибутов в XML-документах. Рассмотрим небольшой пример, который объясняет причины появления этой технологии: представим XML-словарь, в котором элементы с именами «head» и «body используются для описания частей человеческого тела. Предположим, что необходимо добавить в этот документ фрагмент XHTML (будет рассмотрено позднее). XHTML тоже определяет элементы «head» и «body». Возникает вопрос: как же тогда отличить эти XHTML-элементы от одноименных, представленных в главном словаре? Для решения этой задачи предлагается, используя пространства имен XML, назначать каждому словарю свой маркер. В пространствах имен XML каждый словарь называется пространством имен и для выражения маркеров словарей используется специальный синтаксис. Каждый элемент или атрибут может быть связан с одним пространством имен, и, таким образом, можно отличить элемент «head», используемый для описания части тела, от «head» в XHTML. Среди экспертов в области XML отсутствует однозначное мнение в отношении пространств имен, это связано с тем, что эти пространства довольно усложнили модель обработки XML, что сводит на нет все их преимущества. Тем не менее пространства имен превратились в фактически повсеместно признанный стандарт среди пользователей XML и, они задействованы практически во всех технологиях обработки XML.

Документ «Пространства имен XML 1.1» (Namespaces in XML 1.1) [находится в процессе разработки] — это уточненная версия спецификации, в которой учтены дополнения и исправления, а также, помимо прочего, добавлена поддержка локализованных унифицированных локаторов ресурса.

Важный вопрос, который возникает в связи с рассмотрением пространств имен XML, это какие виды ресурсов должны идентифицировать унифицированные идентификаторы ресурсов пространства имен. Эксперты в области XML, ведомые Джонатаном Борденом (Jonathan Borden) и Тимом Брейем (Tim Bray), разработали «Язык описания каталога ресурсов» (Resource Directory Description Language (RDDL)), стандарт для компоновки информации в пространствах имен. Этот стандарт использует XHTML для предоставления текстового описания словаря, в котором для облегчения понимания и обработки пространства имен используются вложенный XLink (см. ниже), который предоставляет указатели на основные ресурсы. Документ RDDL 2.0 [находится в процессе разработки] — это уточненная версия спецификации, в которой предпринята попытка заменить XLink следующими технологиями: "Инфраструктурой описания ресурсов" (Resource Description Framework (RDF)) (будет рассмотрено позднее) и альтернативными предложениями в области задания ссылок XML, которые были выдвинуты в ходе обмена электронными сообщениями, отправляемыми в адрес Группы технического проектирования W3C (W3C Technical Architecture Group, TAG).

RELAX NG

Вспецификации RELAX NG [Спецификация комитета организации OASIS и стандарт ISO] описывается язык XML-схемы, то есть язык, который можно использовать для определения и ограничения XML-словарей. Исходным языком XML-схемы является Document Type Definition (DTD), определенный в XML 1.0. Тем не менее некоторым разработчикам не нравится язык DTD из-за его неудобного синтаксиса, ограниченности в возможности выразить конструкции для текста и разметки, а также из-за сложностей при обработке пространств имен XML. В результате, появилось несколько новых языков XML-схемы, предназначенных для замены или улучшения DTD, включая RELAX NG, который пользуется признанием за свое простоту и выразительность. Основная спецификация RELAX NG определяет синтаксис схем; в спецификации «Компактный синтаксис RELAX NG» (RELAX NG Compact Syntax) [Спецификация комитета организации OASIS] описывается простой текстовый синтаксис для схем RELAX NG. Ожидается, что этот текстовый синтаксис будет включен в стандарт ISO в качестве приложения. RELAX NG — это часть проекта ISO «Языки описания схемы документа» (Document Schema Definition Languages (DSDL)), целью которого является стандартизация систем обработки XML-схем.

Ресурсы

Книга Эллиотта Расти Хэрольда «Библия XML, второе издание» (The XML Bible, 2nd Edition) (издательство Джон Уилей энд Санз (John Wiley & Sons), 2001г.) — наиболее полный и исчерпывающий источник информации об XML. Web-сайты наиболее значимых организаций, занимающихся разработкой XML-стандартов:

Сайт консорциума World-Wide Web (W3C (World Wide Web Consortium)). Сайт Организации по стандартизации структурированной информации (OASIS (Organization for the Advancement of Structured Information Standards)). Сайт Международной организации по стандартизации (International Standards Organization, ISO), особенно той его части, где находится информация о проекте DSDL (ISO/IEC 19757 — Document Schema Definition Languages (DSDL)).

Статья Саймона Ст. Лорента (Simon St. Laurent) «Знакомство с W3C, мнение не члена организации» (Outsider’s Guide to the W3C) написана в форме часто задаваемых вопросов, в которых освещаются многие аспекты деятельности этой организации. Ресурс Робина Ковера (Robin Cover) The Cover Pages содержит информацию практически обо всех существующих XML-технологиях. Новости сайта xmlhack, в редактировании которых часто участвует автор этой статьи. Ряд ресурсов, посвященных XML, в разделе XML (рубрика developerWorks) (developerWorks XML content area), включая колонку автора этой статьи «Размышление о XML» (Thinking XML column). На странице IBM Certified Developer in XML and related technologies приведена информация о том, как стать сертифицированным разработчиком XML.

В первой статье этой серии (first installment) Юч Огбуджи рассматривает базовые XML-технологии (developerWorks, январь 2004г.). Список XML-стандартов в рубрике developerWorks на сайте IBM. Книга Эллиотта Расти Хэрольда «Библия XML, второе издание» (The XML Bible, 2nd Edition) (издательство John Wiley & Sons, 2001г.) — наиболее полный и исчерпывающий источник информации об XML. Web-сайты наиболее значимых организаций, занимающихся разработкой XML-стандартов: Сайт консорциума World-Wide Web (W3C (World Wide Web Consortium)). Сайт Организации по стандартизации структурированной информации (OASIS (Organization for the Advancement of Structured Information Standards)). Сайт Международной организации по стандартизации (International Standards Organization, ISO), особенно той его части, где находится информация о проекте DSDL (ISO/IEC 19757 — Document Schema Definition Languages (DSDL)). Статья Саймона Ст. Лорента (Simon St. Laurent) «Знакомство с W3C, мнение не члена организации» (Outsider's Guide to the W3C) написана в форме часто задаваемых вопросов, в которых освещаются многие аспекты деятельности этой организации. Ресурс Робина Кавера (Robin Cover) «The Cover Pages» содержит информацию практически обо всех существующих XML-технологиях. Новости сайта Xmlhack, в редактировании которых нередко участвует автор этой статьи.

Ряд ресурсов, посвященных XML, в разделе XML (рубрика developerWorks) (developerWorks XML content area), включая колонку автора этой статьи «Размышление о XML» (Thinking XML column). База данных IBM DB2 обеспечивает не только хранение реляционной базы данных, но и инструменты, связанные с XML, как например DB2 XML Extender, который обеспечивает связь между XML и реляционными системами. В разделе DB2 рубрики developerWorks содержится подробная информация о DB2. На странице IBM Certified Developer in XML and related technologies приведена информация о том, как стать сертифицированным разработчиком XML.

SAX

Вспецификации «Простой интерфейс прикладного программирования для XML» (Simple API for XML (SAX)) [Общественный стандарт] описывается управляемый событиями интерфейс прикладного программирования (API). Разработчик регистрирует код обработчика для определенных событий, которые запускаются различными частями разметки XML (как, например, начальный и конечный теги, текст, сущности). Затем парсер, опираясь на входной XML, посылает поток этих событий, которые поочередно обрабатываются кодом обработчика.

SAX явился результатом длительной интерактивной конференции, начатой в 1997 году на ресурсе XML-DEV mailing list, который уже давно является «прибежищем» экспертов в области XML. Эту конференцию вел Дэвид Меггинсон, и ее итогом явилось создание одного из наиболее успешных XML-проектов, в подготовке которого не была задействована ни одна крупная компания или орган стандартизации.

До появления SAX каждый парсер имел свой собственный специфический API, предназначенный для установления связи между структурой XML и кодом обработчика. SAX же обеспечил необходимую унификацию. В большинстве случаев парсеры предоставляют драйверы SAX, которые транслируют низкоуровневые события парсера в стандартные события SAX, предусматривая переносимый код. Несмотря на то, что SAX был разработан с ориентацией на язык Java, он стал популярен среди многочисленных языков и оболочек; хотя иногда его ориентированность на Java усложняет переносимость.

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

В большинстве языков управляемый событиями интерфейс обычно реализуется с помощью функций обратного вызова (стиль, присущий программированию графического пользовательского интерфейса (GUI)). В объектно-ориентированных языках, функции обратного вызова обычно являются зарегистрированными методами для объекта, использующими полиморфизм для сопоставления имени метода с кодом обработчика и инкапсуляцию для управления состоянием в обработчике между обратными вызовами. Эта полная модель управляемого событиями программирования известна как модель проталкивания (push model) и «славится» свой трудностью для освоения.

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

Schematron

Вспецификации «Язык утверждений Schematron 1.5» (The Schematron Assertion Language 1.5) [Общественный стандарт и рабочая версия стандарта ISO] определяется язык схемы, который использует подход, отличный от примененного в DTD, RELAX NG или WXS. Schematron предполагает задание совокупности правил, по которым проверяется XML-документ, а не отображение всей структуры дерева XML-формата, который выражается от корневого узла до листьев. Благодаря этому Schematron оказывается очень удобным не только как язык схемы, но и как дополнение к другим языкам схем. Поскольку на Schematron можно выражать ограничения, которые невозможно записать на других языках схем, перечисленных выше, его часто используют совместно с ними.

SOAP

Вспецификации SOAP [Рекомендация W3C] описывается протокол, предназначенный для использования XML для передачи сообщений между системами, которые связаны с помощью низкоуровневых Интернет-протоколов. Некоторые пользователи рассматривают SOAP как основание Web-сервисов XML — набор технологий для управления и организации взаимодействия систем, связанных с использованием форматов данных XML и Интернет-протоколов передачи сообщений.

Первоначально SOAP разрабатывался небольшой группой, состоящей из частных лиц и различных компаний, в том числе IBM. Он быстро завоевал популярность, поскольку совпал с направлением работ над обменом сообщениями XML, но обеспечил более надежную архитектуру и коммерческую поддержку. Разработка SOAP перешла под эгиду W3C, после чего появился SOAP 1.2, который не смотря на множество архитектурных улучшений, привнес ряд неоднозначны допущений.

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

Поскольку Web-сервисам необязательно использовать SOAP, большая группа разработчиков отстаивает предложение о том, что достаточно просто обмениваться необработанными XML-документами непосредственно через HTTP — подход продвигаемый под знаменами «REpresentational State Transfer (REST)».

Сам REST — это имя, которое дал архитектурному стилю Web один из его архитекторов, Рой Филдинг (Roy Fielding). Сторонники применения этого стиля для Web-сервисов утверждают, что SOAP сложен, ограничивает свою полезную нагрузку XML и не использует в достаточной степени сильные стороны Web.

В лагере приверженцев SOAP недавно произошли изменения: их устремления сместились с корней RPC к тому, что называется стилем document-literal. В соответствии с этим стилем, данные, подлежащие передаче, упаковываются в дискретные типы данных в специальном формате полезной нагрузки XML (называемом кодированием SOAP). При использовании стиля document-literal полезная нагрузка XML состоит из более естественных форматов XML, которые часто более описательны и удобочитаемы для человека.

Список литературы и другие ресурсы

В статье Эндрю Эйзенберга и Джима Мелтона «SQL/XML и Неформальная группа компаний SQLX» (SQL/XML and the SQLX Informal Group of Companies [PDF]) рассказывается о спецификации SQL/XML. В статье Д. Э. Фандербурка (J. E. Funderburk), С. Мэлайки (S. Malaika) и Б. Рейнуолда (B. Reinwald) «Программирование XML с SQL/XML и XQuery» (XML programming with SQL/XML and XQuery [PDF]) (Журнал IBM Systems, том 41, номер 4, 2002г.) проводится очень тщательное исследование всех этих технологий XML и СУБД. Текст рабочей версии спецификации SQL/XML можно заказать в ISO (или в региональном представительстве этой организации), однако, если читатель желает получить общее представление об этом стандарте, автор рекомендует познакомиться с более ранней рабочей версией SQL/XML от марта 2003г. [PDF].

Список литературы идругие ресурсы

«Спецификация XML с аннотациями» (The Annotated XML Specification) Тима Брея (Tim Bray) содержит очень полезные построчные комментарии и уточнения ко всему тексту XML 1.0. «Часто задаваемые вопросы о XML» (The XML FAQ) под редакцией Питера Флинна (Peter Flynn). «Часто задаваемые вопросы о UTF-8 и Unicode для Unix/Linux» (UTF-8 and Unicode FAQ for Unix/Linux) Маркуса Куна (Markus Kuhn) — великолепное справочное пособие для пользователей всех платформ. Ценность этого материала становится понятной, если вспомнить, что UTF-8 — самая распространенная кодировка Unicode. «Unicode в XML и других языках разметки» (Unicode in XML and other Markup Languages) — формальный технический отчет, полезный для читателей (вероятно, разработчиков), которым необходимо очень точное рассмотрение точек пересечения Unicode и XML. На сайте IBM в разделе «Введение в Unicode» (Introduction to Unicode) очень подробно освещены основы Unicode. Ресурс «Открытый каталог ресурсов локализации» (Open Internationalization Resources Directory) — отличный справочный материал, охватывающий все аспекты управления локализованными данными, что является основной целью использования Unicode для XML.

«Часто задаваемые вопросы о пространствах имен XML» (XML Namespaces FAQ) от Рональда Бурре (Ronald Bourret). В эссе Джеймса Кларка (James Clark) «Пространства имен XML» (XML Namespaces) подробно рассматриваются пространства имен, кроме того в ней содержится популярная нотация для их описания. В статье Эллиотта Расти Хэрольда (Elliotte Rusty Harold) «Отыщите мне это: что находит унифицированный локатор пространства имен» (RDDL Me This: What Does a Namespace URL Locate?) является введением в RDDL.

«Справочное пособие по XLink» (XLink Reference) на ресурсе ZVON. В статье Боба дю Шарма (Bob DuCharme) «XLink: кому они нужны» (XLink: Who Cares?) рассматривается история XLink и содержится обзор реализаций этой технологии.

Ссылки на многие ресурсы приводятся на домашней странице RELAX NG (RELAX NG home page). «Справочное пособие по RELAX NG» (RELAX NG Reference) на ресурсе ZVON.

«Справочное пособие по WXS» (WXS reference) на ресурсе ZVON. «Справочное пособие по элементам WXS» (WXS Elements Reference) на ресурсе W3Schools.

На домашней странице Schematron (Schematron home page) и в каталоге ресурсов (resource directory) приведено множество полезных ссылок. «Справочное пособие по Schematron» (Schematron reference) на ресурсе ZVON.

«Справочное пособие по XSLT» (XSLT Reference) на ресурсе ZVON. Страница Дейва Посона (Dave Pawson) «Часто задаваемые вопросы о XSLT» (XSL FAQ) посвящены XSLT и XPath, а также XSL-FO (будет рассмотрено). На ресурсе TopXML приводится более 100 примеров таблиц стилей XSLT, распределенных по категориям. Джени Теннисон (Jeni Tennison) известна своим ясным и четким объяснением многих тонких аспектов XSLT. Страницы XSLT — отличный справочный ресурс, на котором рассматриваются наиболее часто встречающиеся вопросы и проблемы XSLT.

На странице ресурса XML.org — focus on SAX — содержится полезная информация о SAX.

На ресурсе ZVON опубликовано отличное руководство, в котором приводятся многочисленные примеры на JavaScript по DOM Level 1 и DOM Level 2.

Xquery. com — отличный ресурс XQuery, он также включает Wiki, совместный информационный ресурс и место проведения интерактивных обсуждений.

SQL/XML

Спецификация SQL/XML [Международный стандарт ISO/МЭК 9075-14:2003]— это новый раздел стандарта SQL, в котором охвачено множество связанных с XML расширений для SQL. Изначально SQL/XML разрабатывался «Неформальной группой компаний SQLX», в которую входил IBM, затем эта спецификация перешла под эгиду Американского национального института стандартов (ANSI —орган стандартизации, занимающейся SQL). SQL/XML охватывает следующие документы (по словам Эндрю Эйзенберга (Andrew Eisenberg) и Джима Мелтона (Jim Melton)):

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

Спецификация SQL/XML имеет очень мало общего с XQuery, хотя стороны, участвующие в разработке этих спецификаций, обычно работают совместно.

The SOAP edifice

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

Список стандартов Web-сервисов в рубрике developerWorks на сайте IBM. Домашняя страница направления Web-сервисы на сайте консорциума W3C. Webservices.xml.com.

Один из предшественников SOAP, который до сих пор широко используется, это стандарт «Удаленный вызов процедуры на XML» (XML Remote Procedure Calls (XML-RPC)) [Общественный стандарт]. В нем определяются вызовы процедур, закодированные на XML и переданные по HTTP. Эта спецификация остается по-прежнему популярной по причине своей простоты (ее полный текст занимает менее десяти печатных страниц), а также из-за того, что на многих языка и каркасах приложений имеются стандартные и готовые реализации XML-RPC.

Однако, технология XML-RPC обладает рядом существенных недостатков, включая очень примитивный контроль типов данных и отсутствие поддержки кодирования символов (удивительный изъян, если учесть, что в ней используется XML).

WSDL

Согласно официальному определению, спецификация «Язык описания Web-сервисов (WSDL), версия1.2» (Web Services Description Language (WSDL) Version 1.2) [находится в стадии разработки] это «формат XML, предназначенный для описания сетевых сервисов в виде конечных точек, обрабатывающих сообщения, которые содержат ориентированную на документ, либо на процедуру информацию». В этой спецификации на ряде уровней абстрагирования определяются компоненты сквозной передачи в Web-сервисе. Изначально WSDL разрабатывался как совместный проект IBM и Microsoft, но затем был передан в W3C с целью разработки WSDL 1.2. Язык WSDL обычно позиционируется вместе с SOAP, как базовая технология Web-сервисов, но он может быть использован для описания других протоколов помимо SOAP.

XAPI

Вспецификации «Интерфейс прикладного программирования баз данных XML» (XML Database API (XAPI)) [находится в стадии разработки] описывается нейтральный по отношению к поставщику и языку интерфейс прикладного программирования для баз данных XML. XML: DB — это группа разработчиков инструментов управления базами данных XML. Спецификация XAPI охватывает вопросы хранения, извлечения, модификации и задания запросов к данным в базах данных XML, а также предусматривает поддержку управления транзакциями. Она похожа на интерфейс ODBC (Open Database Connectivity interface, открытый интерфейс доступа к базам данных) и интерфейс JDBC (Java Database Connectivity, средство организации доступа Java-приложений к базам данных).

Подобно модели DOM спецификация XAPI определена с использованием языка IDL (Interface Definition Language, язык описания интерфейса) консорциума OMG (Object Management Group, консорциум по технологии манипулирования объектами) и опубликована в виде редакций (по уровням функциональных возможностей). Level 0 — это базовый API, в Level 1 добавлена поддержка XPath (XPathQueryService).

Спецификация XAPI широко используется в инструментах управления «родными» базами данных XML, особенно с открытым кодом, как, например, Apache XIndice и SleepyCat Berkeley XML DB. Помимо спецификации группы XML: DB существует еще несколько Web-ресурсов, посвященных этой технологии. На странице случаи использования API приведено несколько кратких примеров API на языке Java.

XForms

Вспецификации XForms 1.0 [Рекомендация W3C], которую не следует путать с одноименной библиотекой графического пользовательского интерфейса Xwindows, определяются Web-формы для обработки данных XML, которые могут быть использованы со множеством платформ в различных медиа-средах. Цель этой спецификации —отделить предназначение формы от ее представления. Она разделяет то, что делает форма, от того, как она выглядит. Это словарь XML, который можно использовать для разработки пользовательских интерфейсов для манипулирования содержанием XML. Изначально спецификация XForms разрабатывалась как часть семейства XHTML, но затем получила самостоятельное развитие. Хотя она более сложная, чем необходимо, XForms достаточно тщательно проработана для того, чтобы «привнести порядок в безумный мир Web-форм».

XInclude

Вспецификации «Включения XML (XInclude) 1.0» (XML Inclusions (XInclude) 1.0) [находится в процессе разработки] определяется система для объединения XML-документов. Обычно XInclude используется, если необходимо разбить XML-документы на управляемые части. Документы могут быть разбиты произвольным образом, а затем объединены обратно с помощью XInclude. Внешние разобранные сущности (External parsed entities), конструкции XML 1.0, которые позволяют загружать разделы документа из отдельного файла, могут быть использованы аналогичным образом. Некоторые обозреватели отмечают, что XInclude — это ненужная спецификация. Однако, XInclude предлагает некоторые специальные функциональные возможности, в том числе и выбор разделов документа для включения.

XLink

Вспецификации «Расширяемый язык задания ссылок XLink 1.0» (XML Linking Language (XLink) 1.0) [Рекомендация консорциума W3C] определяется общая структура для выражения ссылок в XML-документах. Поскольку основу Web-а составляет гипертекс, связанный при помощи ссылок, реализация возможностей задания сложных ссылок всегда рассматривалась как краеугольный камень XML. На самом деле первоначально XLink называлась «XML, часть 2». К сожалению, определить систему задания ссылок для XML оказалось намного сложнее, чем для статических словарей, как, например, HTML. Спецификация XLink прошла нелегкий и долгий путь разработки и утверждения. Например, разработчики XHTML (будет рассмотрено позднее) решили не использовать XLink и разработали свою собственную систему HLink [находится в процессе разработки]. Даже сегодня, спустя несколько лет после завершения работ над XLink, эта технология пока не пользуется широким признанием.

Тем не менее XLink играет значительную роль, находясь в центре многих важных XML-проектов, и обеспечивает задание гораздо более мощных ссылок по сравнению с простыми однонаправленными ссылками HTML. XLink поддерживает как ссылки HTML (простые ссылки, simple links), так и более сложные, которые могут иметь многочисленные конечные точки (расширенные ссылки, extended links), а также ссылки, которые выражаются не в связанных документах, а в специальных «кольцевых» документах (hub documents), называемых базами связей (linkbases).

XML

Спецификация «XML 1.0 (Второе издание)» (XML 1.0 (Second Edition)) [Рекомендация консорциума W3C (W3C Recommendation)] — это, разумеется, «основной ствол ветвящегося дерева» XML. В ней используется спецификация Unicode [Технический отчет консорциума Unicode и стандарт ISO] для определения жестких правил формирования текстового формата и для задания языка проверки допустимости документа — Document Type Definition (DTD). Нынешнее (втрое издание) этого документа содержит ряд исправлений, накопившихся за время его существования. Эта спецификация переведена на множество языков, хотя только английская версия является нормативной, что означает, что лишь один документ может считаться стандартом.

Спецификация XML 1.1 [находится в процессе разработки] — это первая редакция, в которой изменено определение корректно оформленного (well-formed) XML-документа. Наиболее существенное изменение заключается в пересмотре обработки символов с целью более естественной адаптации спецификации XML к изменениям в стандарте Unicode и обеспечения нормализации символов для различных версий Unicode посредством указания на спецификацию «Модель символов для World Wide Web 1.0» (Character Model for the World Wide Web 1.0) [находится в процессе разработки]. Кроме того, в спецификации XML 1.1 в списке символов конца строки появился символ NEL, используемый для конца строки (EOL) в мейнфреймовых системах IBM. Это дополнение нельзя расценить однозначно — некоторые наблюдатели полагают, что та небольшая польза, которую извлекут пользователи мейнфреймов, не стоит внесения столь существенного изменения. С другой стороны, существует мнение, что все эти нововведения слишком незначительны, чтобы вызвать проблемы с совместимостью различных версий XML.

В основе XML лежит стандартный обобщенный язык разметки (Standard Generalized Markup Language, SGML), определенный в ISO 8879:1986 [стандарт ISO]. XML представляет собой значительно упрощенный вариант SGML, подвергнутый корректировке для лучшего соответствия среде Web.

XML Base

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

XML Infoset

Вспецификации «Информационный набор XML» (XML Information Set) [Рекомендация консорциума W3C], также известной как XML Infoset, определяется абстрактный способ описания XML-документа в виде набора объектов, называемых информационными единицами (information items), обладающих специальными свойствами. Этот абстрактный набор данных объединяет свойства XML-документов, которые определяются в спецификациях XML 1.0, «Пространства имен XML 1.0» и XML Base. Спецификация XML Infoset используется как основание для нескольких других спецификаций, которые пытаются разбить XML-документы на некую совокупность составных объектов.

XML-схема W3C

Вспецификациях «XML-схема, часть 1: структуры» (XML Schema Part 1: Structures) и «XML-схема, часть 2: типы данных» (XML Schema Part 2: Datatypes) [Рекомендации консорциума W3C] определяется еще один язык схемы для XML. Первая спецификация позволяет накладывать ограничения на структуру документа, вторая — на содержание простых элементов и атрибутов. Спецификация XML-схема W3C (W3C XML Schema, WXS) была подвергнута серьезной критике за свою сложность и отсутствие выразительности; результатом чего явилось существование других конкурирующих языков, как, например, RELAX NG. Однако, сейчас пользователи всё чаще просто используют тот язык схемы, который их устраивает больше всего, а затем с помощью одного из широко представленных на рынке инструментальных средств выполняют преобразование из одного языка схем в другой. Несмотря на многочисленные просьбы разработать альтернативные системы типов, в многих других спецификациях используются типы «XML-схема, часть 2: типы данных». Рабочая группа начала работы над WXS 1.1.

XPath

В спецификации XML Path Language (XPath) 1.0 [Рекомендация консорциума W3C] определяются синтаксис и модель данных для адресации частей XML-документа. В ней описываются некоторые функциональные возможности универсального языка выражений. Данная спецификация задумана как простой язык, который можно использовать для не зависящей от приложения обработки в XML-системах. Например, с помощью XPath можно определять в документе место элементов, являющихся заголовками разделов.

XPath, пожалуй, самая успешная XML-технология, за исключением XML 1.0. Она является основой XSLT (будет рассмотрено позднее), очень удачного языка трансформаций XML, поддерживается практически во всех платформах, предназначенных для обработки XML. В спецификации XPath 2.0 [находится в процессе разработки] предусматривается значительное расширение функциональных возможностей, включая поддержку XML-схемы W3C (см. ниже) и множество новых базовых функций. Эта спецификация вызывает весьма неоднозначные оценки — по причине своей крайней сложности; многие пользователи и разработчики, включая автора этой статьи, утверждают, что не будут ее использовать, если только эта версия языка не будет существенно упрощена.

XPointer

Спецификация «Структура расширяемого языка указателей» (XPointer Framework) [Рекомендация консорциума W3C] определяет язык, который можно использовать для указания фрагментов XML-документа. Вероятно, читатель уже знаком стем, как использовать унифицированные локаторы ресурса со знаком решетки («#»), чтобы связываться с отдельным разделом HTML-документа. Язык XPointer характеризуется аналогичными, но гораздо более широкими возможностями по заданию ссылок или сносок на XML-документы. Эту структуру можно использовать с xpointer() scheme [находится в процессе разработки], element() scheme [Рекомендация консорциума W3C] и xmlns() scheme [Рекомендация консорциума W3C], в которых определены специальные инструкции для выражения интересуемых фрагментов документа в рамках структуры XPointer.

История разработки и принятия этой спецификации довольно непростая. Так, сами члены Рабочей группы разработали спецификацию FIXptr [Общественный стандарт (Community Standard)], являющуюся полной противоположенностью XPointer. Некоторые альтернативные схемы XPointer включают xpath1() scheme [Рабочий вариант Интернет-документа Целевой группы инженерной поддержки Internet (IETF Internet Draft)].

XQuery

Вспецификации «XQuery: язык запросов XML» (XQuery 1.0: An XML Query Language) [находится в стадии разработки] определяется, как формировать запросы к источникам данных XML.

XQuery — это в значительной степени язык программирования, представляющий собой подмножество XPath. XQuery разрабатывается совместно с XPath 2.0 и вызывает неоднозначные оценки в свой адрес, поскольку, по мнению многих, характеризуется излишней сложностью. Спецификации XQuery 1.0/XPath определяются в многочисленных редакциях, в которых описывается семантика, синтаксис и библиотеки базовых функций:

В спецификации «Случае использования XQuery» (XML Query Use Cases) [находится в стадии разработки] на примерах рассматриваются сценарии использования XQuery. В спецификации «Модель данных XQuery 1.0 и XPath 2.0» (XQuery 1.0 and XPath 2.0 Data Model) [находится в стадии разработки] определяется информация, содержащаяся во входном файле, передаваемом в процессор XSLT 2.0 или XQuery, а также все допустимые значения выражений в XSLT 2.0, XQuery и XPath 2.0. В спецификации «Формальная семантика XQuery 1.0 и XPath 2.0» (XQuery 1.0 and XPath 2.0 Formal Semantics) [находится в стадии разработки] приводится формальное объяснение каждого выражения спецификаций XPath 2.0 и XQuery 1.0 в терминах их модели данных. В спецификации «XPath 2.0» (XPath 2.0) [находится в стадии разработки] описывается базовый синтаксис XPath 2.0.

В спецификации «Функции и операторы XQuery 1.0 и XPath 2.0» (XQuery 1.0 and XPath 2.0 Functions and Operators) [находится в стадии разработки] определяются общие задачи обработки, используемые в выражениях. В спецификации XQuery 1.0 [находится в стадии разработки] описывается базовый синтаксис XQuery 1.0. В спецификации «Синтаксис XML для XQuery 1.0 (XQueryX)» (XML Syntax for XQuery 1.0 (XQueryX)) [находится в стадии разработки] содержится факультативное XML-представление XQuery. В спецификации «Сериализация XSLT 2.0 и XQuery 1.0» (XSLT 2.0 and XQuery 1.0 Serialization) [находится в стадии разработки] описывается, как выглядят значения модели данных в XML, HTML и тексте, фактически в этом документе указывается, как можно заменить раздел XSLT в выходных данных процессора. Спецификации XSLT 2.0 [находится в стадии разработки] не входит непосредственно в семейство XQuery, но тесно связана с XPath 2.0 и XQuery 1.0 и полностью не зависит от первой.

XSLT

Вспецификации «Преобразования расширяемого языка стилей» (Extensible Stylesheet Language Transformations (XSLT) 1.0) [Рекомендация W3C] определяется язык, используемый для описания преобразований входного XML-документа в выходное дерево. Выходное дерево может, например, принять форму HTML-документа или другого XML-формата и, таким образом, XSLT может считаться языком, предназначенным для преобразования XML в форму представления традиционного браузера или для обработки XML-файлов с помощью скриптов. Это преобразование представляет собой XML-документ, определенный в отдельном словаре, а для обращения к исходному документу и выполнения общих операций обработки используются выражения спецификации XPath (рассмотренной ранее). Специальные инструкции устанавливают правила обработки (XSLT является декларативным языком) и управляют процессом создания выходного дерева.

Спецификация XSLT 1.0 пользуется исключительной популярностью, и с помощью языка XSLT можно решить большинство типичных задач обработки XML. Если читатель знаком с XML, то ему не составит труда изучить основы XSLT, хотя для полного овладения этим языком потребуются некоторые усилия. XSLT обладает хорошо спроектированным механизмом расширений, а его декларативная модель обработки допускает многократное использование кода. В спецификации «Ассоциирование таблиц стилей с XML-документами, версия 1.0» (Associating Style Sheets with XML documents, Version 1.0) [Рекомендация W3C] описывается стандартный способ связывания XML-документа с документом таблицы стилей XSLT. Спецификация XSLT была переведена на многие языки.

Как уже было указано выше, XSLT располагает великолепным механизмом расширения, с помощью которого можно определять дополнительные функциональные возможности, используя какой-либо язык. Однако, что еще более приятно, часто самому не нужно писать расширения, поскольку многие из них уже написаны. В спецификации EXSLT [Общественный стандарт] определен стандартный набор таких расширений, основной особенностью которых является стремление избежать зависимость от какой-либо конкретной реализации.

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

Хотя спецификация XSLT 2.0 [находится в стадии разработки] была подвергнута принципиальной доработке с учетом коллективного опыта использования XSLT 1.0, и эта версия XSLT не лишена изъянов, будучи тесно связанной с языком XPath 2.0, который, по мнению автора, имеет существенные недостатки.

XUpdate

Вспецификации XUpdate [находится в стадии разработки] определяются обновленные функциональные возможности для модификации данных в XML-документах. Несмотря на то, что эта спецификация разрабатывается группой XML: DB, XUpdate предназначен для работы с регулярными XML-документами, а также с XML-документами в совокупностях баз данных и даже с виртуальными моделями данных XML.

XUpdate — это схожий с XSLT словарь XML, к которому очень легко обращаться. Подобно XSLT, для обращения к документу, который необходимо модифицировать, в нем используются выражения XPath, а также специальные элементы, которые определяют операции вывода. XUpdate широко реализован, в основном среди инструментов с открытым кодом, как, например, системы управления базами данных XML и инструментами для выявления различия между XML-документами и внесения необходимыз изменений (difference and patching tools).

Черновой вариант документа «Случаи использования XUpdate» (XUpdate Use Cases) — прекрасное введение в эту технологию.

Использование возможностей абстрактных отношений Infoset

Код примера

Конкретизация при добавлении компонентов и манипулировании ими

Корректирование XML-схем: получение схем, удобных для SOAP

Краткое изложение применяемого подхода

Переписывание схемы

"Подчистите" свою схему для SOAP

Ресурсы

Визуальное редактирование схемы

пример очистки XML-документа

Замена атрибутов элементами

Фрагмент кода разработанной таксономии

Фрагмент кода реального документа

Некоммерческое партнерство "Стандарты

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

CSS

DOM

Языки программирования для XML

Канонический XML («c14n»)

Каталоги

Многообразие стандартов

Обавторе

Обзор XML-стандартов, часть 1Базовые XML-стандарты- основа основ

Обзор XML-стандартов, часть 2Стандарты для обработки XML

Продолжение следует

Пространства имен

Рекомендуемые обучающие руководства и учебные пособия

Рекомендуемые обучающие руководства иучебные пособия

RELAX NG

Ресурсы

SAX

Schematron

SOAP

Список литературы и другие ресурсы

Список литературы идругие ресурсы

SQL/XML

The SOAP edifice

WSDL

XAPI

XForms

XInclude

XLink

XML

XML Base

XML Infoset

XML-схема W3C

XPath

XPointer

XQuery

XSLT

XUpdate