Поделиться через

Работа с XML-схемами в InfoPath

В шаблоне формы, создаваемом с помощью Microsoft InfoPath, схема XML (XSD) используется для выполнения проверки данных в XML, который представляет вводные, отредактированные и выводные данные из формы InfoPath. Каждый шаблон формы, созданный в конструкторе форм InfoPath, содержит как минимум один файл схемы XSD (XSD), используемый для проверки во время выполнения.

Примечание.

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

Использование созданных во внешней среде схем XML

Чтобы загрузить файл схемы XSD, созданный вне приложения InfoPath, выполните следующие действия.

Создание шаблона формы на основе внешней схемы

  1. В Backstage, нажмите Создать, щелкните XML или схему в разделе Дополнительные шаблоны форм, а затем нажмите Создать форму.

  2. В мастере источника данных, укажите нужный файл схемы XSD, а затем нажмите кнопку Далее и следуйте инструкциям на оставшихся страницах мастера.

Неподдерживаемые конструкции XSD

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

Типы ENTITY и ENTITIES

Для типов ENTITY и ENTITIES требуется определение типа документа (DTD), которое не поддерживается в InfoPath. В InfoPath не допускается разработка шаблона формы по такой схеме и выводится сообщение об ошибке с рекомендацией изменить тип ENTITY на тип NCName, производным которого является ENTITY.

Примечание.

Если шаблон формы InfoPath создается вручную не в режиме конструктора и в этом шаблоне используется XSD с типами ENTITY и ENTITIES, шаблон формы может работать во время выполнения в случае, если файл Template.xml содержит необходимый DTD для этих типов.

Обязательный элемент "xsd:any"

Экземпляр элемента подстановочного знака xsd:any, то есть экземпляр элемента xsd:any со значением атрибута minOccurs больше нуля ("required any"), запрещает детерминированное создание в InfoPath допустимого экземпляра для данного фрагмента схемы. При генерировании формы, использующей этот фрагмент схемы, в приложении InfoPath должна быть возможность создания допустимого экземпляра. Выполняя действия в мастере источника данных, при работе со схемами, имеющими обязательные элементы xsd:any, потребуется выбрать элемент схемы, который будет использоваться вместо обязательного элемента xsd:any.

Элементы абстрактного сложного типа

Режим конструктора InfoPath поддерживает разработку шаблона формы в схемах, использующих абстрактные сложные типы. Например, если элемент с именем shippingAddress имеет абстрактный сложный тип с именем address с двумя производными и CanadianAddressUSAddress , InfoPath обрабатывает любой shippingAddress экземпляр как выбор между shippingAddress типом USAddress и shippingAddress с типом CanadianAddress. В этом примере, если указанные схемы не содержат типов, производных от адреса, InfoPath запрашивает дополнительную схему, удовлетворяющую данному требованию.

Конструкции XSD с ограниченной функциональностью

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

Группы подстановки

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

Неограниченные элементы выбора

В следующем фрагменте схемы представлен неограниченный элемент выбора:

<xsd:choice maxOccurs="unbounded"> 
    <xsd:element name="my_element_1"/> 
    <xsd:element name="my_element_2"/> 
</xsd:choice>

В приложении InfoPath повторяющиеся элементы выбора отображаются в виде повторяющихся вариантов в области задач Поля. Элемент управления Повторяющаяся группа выбора можно использовать для представления разнородного списка, определенного повторяющимся элементом выбора в XSD.

Повторяющаяся последовательность

В следующем фрагменте схемы представлена повторяющаяся последовательность:

<xsd:sequence maxOccurs="unbounded"> 
    <xsd:element name="my_element_1"/> 
    <xsd:element name="my_element_2" minOccurs="0"/> 
</xsd:sequence>

До тех пор пока в повторяющейся последовательности будет находиться необходимый элемент, приложение InfoPath будет загружать XSD без изменений, позволяя выполнять привязку элементов управления повторяющегося раздела к повторяющейся последовательности.

Выбор групп моделей

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

<xsd:choice> 
    <xsd:element name="my_element_1"/> 
    <xsd:sequence> 
        <xsd:element name="my_element_2"/> 
        <xsd:element name="my_element_3"/> 
    </xsd:sequence> 
</xsd:choice>

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

Необязательный элемент того же уровня с тем же классифицированным именем

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

<xsd:sequence> 
    <xsd:element name="my_element_1" minOccurs="0"/> 
    <xsd:element name="my_element_2"/> 
            <xsd:element name="my_element_1"/> 
</xsd:sequence>

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

Конструкции XSD, имеющие особое значение в InfoPath

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

Добавление новых полей и групп элементов с помощью области задач "Поля"

Схему можно построить так, чтобы использовать область задач Поля для добавления новых полей и групп элементов во время разработки. Для этого элемент в схеме необходимо объявить с помощью дополнительного неограниченного элемента xsd:any, который указывает атрибут пространства имен с подстановочным знаком ##any. Затем в режиме конструктора можно использовать область задач Поля для добавления к элементу новых полей и групп. Например, новый контент можно добавить к следующему элементу.

<xsd:element name="open"> 
    <xsd:complexType> 
         <xsd:sequence> 
             <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##any"processContents="lax"/> 
         </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

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

Так же как и в случае с элементом, разработчик может объявить атрибут с элементом anyAttribute с атрибутом пространства имен в виде подстановочного знака ##any. Во время разработки область задач Поля используется для добавления нового контента к этому атрибуту схемы.

<xsd:element name="open"> 
    <xsd:complexType> 
        <xsd:anyAttribute namespace="##any" processContents="lax"/> 
    </xsd:complexType> 
</xsd:element>

Хранение подписей XML в источнике данных

Чтобы пользователи могли во время выполнения ставить на форму цифровую подпись, схема источника данных должна объявить именованную подпись элемента для хранения данных о подписях XML (цифровой подписи), которые создаются при подписывании формы пользователем. Это объявление можно сделать с помощью элемента xsd:any с атрибутом пространства имен, указанным в качестве пространства имен XML Signatures с подстановочным знаком, как показано ниже: "https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"

<xsd:element name="signature"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:any namespace="https://www.w3c.org/2000/09/xmldsig#"  
             processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
        <xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

Привязка поля к элементу управления "Rich Text Box"

Элементы управления Rich Text Box в InfoPath предназначены для создания общих XHTML; следовательно, схема должна указывать, что в XML и экземпляре формы является допустимым любое число узлов текста и XHTML. Для формирования такой спецификации служит следующая конструкция XSD.

<xsd:element name="xhtml"> 
    <xsd:complexType mixed="true"> 
        <xsd:sequence> 
            <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="https://www.w3.org/1999/xhtml" processContents="lax"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

Примечание.

InfoPath никогда не изменяет содержимое файла схемы XSD, но при разработке приложение может логически вывести его подмножество. Файл схемы в рамках шаблона формы никогда не изменяется как во время разработки, так и во время выполнения.

Общие ошибки отладки XSD

Если созданные во внешней среде файлы XSD загружаются для создания шаблонов форм в конструкторе форм InfoPath, возможен вывод следующих типов сообщений об ошибках: сообщения об ошибках MSXML или сообщения об ошибках InfoPath. Сообщения об ошибках MSXML отображаются в разделе Сведения диалогового окна сообщения об ошибках InfoPath и всегда начинаются со ссылки на имя пути к файлу схемы, вызвавшему ошибку. В InfoPath поддерживаются лишь некоторые допустимые конструкции схемы XSD; они рассматриваются в разделе "Неподдерживаемые конструкции XSD". В следующих разделах представлено описание общих ошибок, которые могут привести к сбоям загрузки схем в InfoPath.

Объявление пространства имен XSD

Аналогично всем стандартам W3C схемы XML (XSD) прошли длительный процесс экспертной оценки, прежде чем стать рекомендуемым средством. Существовало множество рабочих проектов и, соответственно, на основе новых устанавливаемых стандартов было создано много XSD-файлов. В ходе этого процесса корпорация Майкрософт разработала специальный язык схемы, XML-Data Reduced (XDR), который был включен в MSXML 3.0. Начиная с выпуска MSXML 4.0 основные службы XML Майкрософт поддерживают полную рекомендацию XSD. Многие программы по созданию схем не использовали XSD до полной рекомендации. В более старых версиях этих программ могут быть созданы устаревшие файлы XSD, не поддерживаемые инфраструктурой MSXML 5.0, от которой зависит InfoPath.

Чтобы убедиться, что файл XSD поддерживает полную рекомендацию XSD, он должен содержать в теге <schema> следующее объявление пространства имен:

xmlns:xsd="https://www.w3.org/2001/XMLSchema"

Подобно всем объявлениям пространства имен XML префиксом XML (в данном случае "XSD") может быть любая допустимая строка префикса. Наиболее распространены префиксы "XSD", "XS" и "" (префикса нет). Если это объявление пространства имен отсутствует, MSXML обычно сообщает об ошибке, связанной с неправильным определением корня.

Импорт и включение схем

Схемы XSD являются расширяемыми и могут импортировать и включать в свой состав другие схемы. Обычно импорт схемы выполняется, если указанная в атрибуте targetNamespace схема отличается от текущей схемы. Схему необходимо включить в другую, если указанная в атрибуте targetNamespace схема совпадает с текущей.

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

<xsd:import namespace = "[anyURI]" schemaLocation = "[anyURI]"/> 
<xsd:include schemaLocation = "[anyURI]"/>

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

Примечание.

Ошибки, вызванные проблемами с атрибутом schemaLocation, представляют сложность только при первом импорте InfoPath схем; то есть при первой разработке формы на основе существующей схемы. После этого InfoPath работает с кэшированными версиями файлов схемы, сохраненных в шаблоне формы.

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

Недетерминированные схемы

Инфраструктура MSXML 5.0, от которой зависит приложение InfoPath, может с большой вероятностью выявлять и выводить ошибки для оповещения о недетерминированных схемах, однако в итоговых сообщениях об ошибках не указывается номер строки, определяющий часть схемы, вызвавшую ошибку. В этом разделе рассматриваются вопросы о детерминированности файлов схемы XSD, а также объясняется значение недетерминированности. Здесь представлены и общие ошибки, которых следует избегать.

Схемы XSD существуют для проверки структуры данных XML и семантик типов. Для решения этой задачи система проверки (в данном случае MSXML 5.0) должна сопоставить узлы XML объявлениям XSD. Без этого сопоставления проверка не выполняется. Если сопоставление гарантировано, то схема является детерминированной. Если существует один экземпляр XML, делающий сопоставление невозможным, схема является недетерминированной.

В следующем примере представлена недетерминированная схема.

<xsd:element name="file_Information"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element name="file_name"/> 
            <xsd:choice> 
                <xsd:element name="file_path"/> 
                <xsd:sequence> 
                    <xsd:element name="file_path" minOccurs="0"/> 
                    <xsd:element name="URI"/> 
                </xsd:sequence> 
            </xsd:choice> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

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

<file_Information> 
    <file_name>my_Schema.xsd</file_name> 
    <file_path>c:\xsd</file_path> 
</file_Information>

В этом фрагменте XML не ясно, является ли <элемент file_path> обязательным узлом из первой части объявления выбора или необязательным из второй части объявления выбора. Это различие очень важно по следующим причинам.

  1. Если фрагмент XML проверен по первой части объявления выбора, тогда XML считается допустимым в данной схеме.

  2. Если фрагмент XML проверен по второй части объявления выбора, тогда схема признается недопустимой из-за отсутствия необходимого узла <URI>.

Некоторые системы проверки XSD не выдают ошибки при проверке по данной схеме, поскольку существует допустимый путь. MSXML является более жестким и выводит ошибку о недетерминированности схемы.

Ниже приведены еще несколько примеров недетерминированных схем. Первый относится к необязательным элементам. Эти случаи часто возникают из преобразователей XDR в XSD из-за различий в кратности по умолчанию в двух языках схем. В первом случае следует рассмотреть необязательные элементы, объявленные элементами xsd:choice и xsd:sequence . Необязательные элементы, объявленные в элементе xsd:sequence , обычно проверяют правильно, если у вас нет элементов с одинаковым именем более одного раза, а между ними — только необязательные элементы. Например:

<xsd:element name="container"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element ref="aNode" /> 
            <xsd:element ref="anotherNode" minOccurs="0"/> 
            <xsd:element ref="aNode" /> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

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

<container> 
    <aNode/> 
    <aNode/> 
    <anotherNode/> 
</container>

Глядя на этот фрагмент, можно понять, почему он недопустим: перед элементом <anotherNode> есть два <aNode> элемента, если разрешен только один.

Теперь предположим, что нужно проверить следующий экземпляр XML.

<container> 
    <aNode/> 
    <aNode/> 
</container>

Сложность заключается в определении действительности экземпляра. Есть ли два <aNode> элемента, где разрешен только один, или элемент, <aNode> где это разрешено, и другой, где это разрешено? Схема является недетерминированной, поскольку узнать ответ невозможно.

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

<xsd:choice> 
    <xsd:element name="node" minOccurs="0"/> 
</xsd:choice>

Последней сомнительной практикой является использование элемента xsd:any без определения пространства имен, как в <xsd:any namespace="##other"/> , после элемента xsd:sequence . Эта конструкция вносит особые сложности, когда следует за дополнительным элементом. При повторном обращении к предыдущему примеру и изменении последнего узла на элемент xsd:any видно, что предыдущие аргументы о недетерминированности по-прежнему применимы, как показано далее.

<xsd:element name="container"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element ref="aNode" /> 
            <xsd:element ref="anotherNode" minOccurs="0"/> 
            <xsd:any />     
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

Недопустимые значения перечисления

Обычно схемы XSD не выполняют никаких проверок до тех пор, пока не будет проверен фактический документ экземпляра. Исключением является наличие в схеме перечисления. В этом случае схема проверяет значения перечисления по типам перечисления, чтобы гарантировать, что они представляют правильные значения узлов. Далее приведено два примера.

<xsd:simpleType name="showTimes"> 
    <xsd:restriction base="xsd:time"> 
        <xsd:enumeration value="18:30:00"/> 
        <xsd:enumeration value="20:45:00"/> 
        <xsd:enumeration value="eleven o'clock"/> 
    </xsd:restriction> 
</xsd:simpleType>

Эта схема недопустима, поскольку значение "eleven o'clock" не является допустимым для элемента типа xsd:time.

Далее приведен более сложный пример.

<xsd:simpleType name="concession"> 
    <xsd:restriction base="xsd:NMTOKEN"> 
        <xsd:enumeration value="GummyBears"/> 
        <xsd:enumeration value="SnowCaps"/> 
        <xsd:enumeration value="M&Ms"/> 
    </xsd:restriction> 
</xsd:simpleType>

Чтобы понять причину, по которой этой пример признается недействительным, необходимо разобраться в способе определения типа xsd:NMTOKEN. В спецификации типов данных W3C тип NMTOKEN определен следующим образом: "NMTOKEN (маркер имени) — это сочетание символов имени."

При дальнейшем изучении становится ясно, что "&" не является допустимым символом имени, и поэтому "M&Ms" не проходит проверку в качестве типа NMTOKEN.

Пустые элементы последовательности или выбора

Иногда MSXML выдает ошибки об объявлениях схемы, содержащих пустые элементы xsd:choice или xsd:sequence, как показано в следующем примере.

<xsd:element name="emptyContainer"> 
    <xsd:complexType> 
        <xsd:choice /> 
    </xsd:complexType> 
</xsd:element>

Удаление пустого <xsd:choice /> тега должно устранить эту проблему.

Регулярные выражения

В MSXML 5.0 могут возникнуть проблемы с проверкой шаблонов регулярных выражений при нагрузке. Регулярные выражения могут быть сложными, и при их использовании следует соблюдать осторожность. Каждое средство синтаксического анализа XSD имеет гибкие языки регулярных выражений; то есть они реализуют официальный язык регулярных выражений XSD плюс элементы из других языков регулярных выражений. Если в конструкторе форм InfoPath возникают проблемы при синтаксическом анализе регулярного выражения, то создаваемые InfoPath примеры данных могут быть недопустимыми или вообще не созданы. Это допустимо во время разработки, так как InfoPath использует только образцы данных для форматирования. Однако если вы используете регулярное выражение, которое не поддерживает MSXML, InfoPath не сможет проверить значение при заполнении формы. Схема XML, часть 0. Primer Second Editionописывает, что поддерживается в регулярных выражениях XSD. Дополнительные сведения о регулярных выражениях XSD и регулярных выражениях уровня Юникода 1 см. в разделе Регулярные выражения Юникода.

Проблемы, связанные с атрибутом "targetNamespace"

XSD интересен тем, что по умолчанию атрибут targetNamespace ссылается только на объявления верхнего уровня, хотя можно задать attributeFormDefault=qualified и elementFormDefault=qualified переопределить это поведение по умолчанию. В качестве примера предположим, что в наличии имеется следующий файл XSD.

<xsd:schema xmlns:xsd="https://www.w3.org/2001/XMLSchema" targetNamespace="https://ns" > 
    <xsd:element name="root"> 
        <xsd:complexType> 
            <xsd:sequence> 
                <xsd:element name="local"/> 
            </xsd:sequence> 
        </xsd:complexType> 
    </xsd:element> 
</xsd:schema>

И далее, документ XML выглядит следующим образом.

<ns:root xmlns:ns="https://ns"> 
    <local/> 
</ns:root>

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

<xsd:schema xmlns:xsd="https://www.w3.org/2001/XMLSchema" targetNamespace="https://ns" > 
    <xsd:element name="root"> 
        <xsd:complexType> 
            <xsd:sequence> 
                <xsd:element ref="global"/> 
            </xsd:sequence> 
        </xsd:complexType> 
    </xsd:element> 
 
    <xsd:element name="global"/> 
</xsd:schema>

Эта схема недопустима, так как "global" находится в пространстве имен "https://ns". Простой ref="global" не распознается, так как пространство имен по умолчанию не "https://ns". Для устранения этой ошибки необходимо добавить префикс для конечного пространства имен и применять его для всех глобальных ссылок и использований типов. Исправленная схема выглядит следующим образом.

<xsd:schema xmlns:xsd="https://www.w3.org/2001/XMLSchema"  
    xmlns:ns="https://ns" targetNamespace="https://ns" > 
    <xsd:element name="root"> 
        <xsd:complexType> 
            <xsd:sequence> 
                <xsd:element ref="ns:global"/> 
            </xsd:sequence> 
        </xsd:complexType> 
    </xsd:element> 
 
    <xsd:element name="global"/> 
</xsd:schema>

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

Кодировка инструкции обработки XML (Юникод и ANSII)

XML поддерживает только наборы символов в кодировке Юникод. Поэтому при сохранении файлов с символами ANSII данные могут быть потеряны. Сохранение же файлов в кодировке UTF-16 может быть излишним. Чтобы сократить затраты на внедрение средство чтения XML, автор XML-документа должен указать используемую кодировку в инструкции обработки XML. Можно распознать следующую знакомую инструкцию обработки.

xml version="1.0" encoding="UTF-8"

Этот тег инструкции обработки указывает, что файл имеет кодировку UTF-8. Необходимо убедиться, что кодировка файла совпадает с кодировкой, определенной в теге инструкции обработки. Чтобы определить кодировку, можно посмотреть на байты файла и найти отметки порядка байт Юникода. Однако есть более простой способ. При возникновении трудностей с открытием схемы XSD нужно выбрать кодировку UTF-8, открыть схему в текстовом редакторе (например, в Блокноте), а затем сохранить файл с помощью кодировки UTF-8 (в Блокноте в диалоговом окне Сохранить как есть раскрывающийся список Кодировка). Если файл по-прежнему не открывается, проблема не связана с кодировкой.

Атрибут "maxOccurs" в элементе "xsd:all"

В связи со способом определения недетерминизма в рекомендации для схемы XML единственным допустимым значением для атрибута maxOccurs элемента xsd:element в элементе xsd:all является 1. Например, допустимо следующее.

<xsd:all> 
    <xsd:element name="x" minOccurs="0"/> 
    <xsd:element name="docs" minOccurs="0"/> 
</xsd:all>

Однако данный пример не является допустимым.

<xsd:all>     
    <xsd:element name="x" minOccurs="0" maxOccurs="unbounded"/> 
    <xsd:element name="docs" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:all>

Этот пример недопустим, так как система проверки не может определить, сопоставляется <x/> ли два вхождения с одним объявлением или с объявлением и другим недопустимым определением. В одном и том же формате нельзя иметь два элемента с одинаковым именем в теге <xsd:all> .

Этот пример также интересен тем, что он позволяет иметь любое количество <x/> узлов и <docs/> внутри содержащего элемента в любом порядке. Несмотря на недопустимость этой структуры, существует обходной метод. Для достижения результата, показанного в следующем примере, можно использовать элемент xsd:choice.

<xsd:choice minOccurs="0" maxOccurs="unbounded"> 
    <xsd:element name="x" /> 
    <xsd:element name="docs" /> 
</xsd:choice>

Изменение или создание XSD для InfoPath

В следующих разделах приведены два примера по изменению и созданию схемы для вывода в InfoPath определенных результатов.

Вставка определенных пользователем элементов в область задач "Поля"

Чтобы определенные пользователем элементы могли отображаться в рамках родительского элемента в области задач Поля, в родительский элемент необходимо вставить элемент xsd:any. Чтобы разрешить вставку пользовательских элементов в , <your_node_name>объявление XSD должно выглядеть следующим образом.

<xsd:element name="your_node_name"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:any namespace="##any | ##other"  
                minOccurs="0" maxOccurs="unbounded"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

Если вы также хотите разрешить определяемые пользователем атрибуты, необходимо добавить <xsd:anyAttribute namespace="##any | ##other"/> в объявление элемента.

Привязка элементов "Rich Text" в режимах конструктора и правки InfoPath

Если вы хотите объявить элемент, который можно привязать к элементу управления Rich Text Box , он должен иметь следующую форму, включающую элемент xsd:any с атрибутом пространства имен , для которого задано значение "https://www.w3.org/1999/xhtml" Как показано в следующем примере.

<xsd:element name="your_node_name"> 
    <xsd:complexType mixed="true"> 
        <xsd:sequence> 
            <xsd:any namespace="https://www.w3.org/1999/xhtml"  
                minOccurs="0" maxOccurs="unbounded"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

Заключение

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

См. также