« Предыдущий • След • Затем »

Проверка допустимости с XML-схемой

Этот раздел смотрит на процесс проверки допустимости XML-схемы. Хотя полная обработка XML-схемы выходит за рамки этого учебного руководства, этот раздел показывает Вам шаги, которые Вы делаете, чтобы проверить XML-документа, используя определение XML-схемы. (Чтобы узнать больше о XML-схеме, можно рассмотреть онлайновое учебное руководство, Часть 0 XML-схемы: Учебник для начинающих. В конце этого раздела Вы также изучите, как использовать определение XML-схемы, чтобы проверить документа, который содержит элементы от многократных пространств имен.

Краткий обзор Процесса Проверки допустимости

Чтобы быть уведомленным относительно ошибок проверки допустимости в XML-документе, следующее должно быть истиной:

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

Конфигурирование Фабрики `DocumentBuilder`

Полезно запуститься, определяя константы, которые Вы будете использовать, конфигурируя фабрику. Они - те же самые константы, которые Вы определяете при использовании XML-схемы для парсинга SAX, и они объявляются в начале примера программы DOMEcho.

static final String JAXP_SCHEMA_LANGUAGE =
    "http://java.sun.com/xml/jaxp/properties/schemaLanguage";
static final String W3C_XML_SCHEMA =
    "http://www.w3.org/2001/XMLSchema";

Затем, Вы конфигурируете DocumentBuilderFactory, чтобы генерировать осведомленный о пространстве имен, проверяющий синтаксический анализатор, который использует XML-схему. Это делается, вызывая метод setValidating на экземпляре DocumentBuilderFactory dbf, который создавался в, Инстанцируют Фабрики.

// ...

dbf.setNamespaceAware(true);
dbf.setValidating(dtdValidate || xsdValidate);

if (xsdValidate) {
    try {
        dbf.setAttribute(JAXP_SCHEMA_LANGUAGE, W3C_XML_SCHEMA);
    }
    catch (IllegalArgumentException x) {
        System.err.println("Error: JAXP DocumentBuilderFactory attribute " 
                           + "not recognized: " + JAXP_SCHEMA_LANGUAGE);
        System.err.println("Check to see if parser conforms to JAXP 1.2 spec.");
        System.exit(1);
    }
}

// ...

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

Соединение Документа со Схемой

Теперь, когда программа готова проверить с определением XML-схемы, необходимо только гарантировать, что XML-документ связывается с (по крайней мере) одним. Есть два способа сделать это:

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

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

Чтобы определить определение схемы в документе, Вы создали бы XML как это:

<documentRoot xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation='YourSchemaDefinition.xsd'> [...]

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

Можно также определить файл схемы в приложении, которое имеет место для DOMEcho.

static final String JAXP_SCHEMA_SOURCE =
    "http://java.sun.com/xml/jaxp/properties/schemaSource";
        
// ...

dbf.setValidating(dtdValidate || xsdValidate);
if (xsdValidate) {
    // ...    
}

if (schemaSource != null) {
    dbf.setAttribute(JAXP_SCHEMA_SOURCE, new File(schemaSource));
}

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

Проверка допустимости с Многократными Пространствами имен

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

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

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

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

<employee id="...">
  <name>....</name>
  <tax:form>
     ...w2 tax form data...
  </tax:form>
  <hiring:form>
     ...employment history, etc....
  </hiring:form>
</employee>

Содержание элемента tax:form, очевидно, отличалось бы от содержания элемента hiring:form и должно будет быть проверено по-другому.

Отметьте, также, что в этом примере есть пространство имен по умолчанию, которому принадлежат неполные имена элементов employee и name. Для документа, который будет должным образом проверен, схема для того пространства имен должна быть объявлена, так же как схемы для пространств имен hiring и tax.

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

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

Объявление Схем в Наборе Данных XML

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

<documentRoot
  xmlns:xsi=
  "http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation=
    "employeeDatabase.xsd"
  xsi:schemaLocation=
  "http://www.irs.gov.example.com/ 
   fullpath/w2TaxForm.xsd
   http://www.ourcompany.example.com/ 
   relpath/hiringForm.xsd"
  xmlns:tax=
    "http://www.irs.gov.example.com/"
  xmlns:hiring=
    "http://www.ourcompany.example.com/"
>

Объявление noNamespaceSchemaLocation - что-то, что Вы видели прежде, как последние две записи, которые определяют префиксы пространства имен tax и hiring. То, что ново, является записью в середине, которая определяет расположения схем, чтобы использовать для каждого пространства имен, на которое ссылаются в документе.

Объявление xsi:schemaLocation состоит из пар записи, где первая запись в каждой паре является полностью определенным URI, который определяет пространство имен, и вторая запись содержит полный путь или относительный путь к определению схемы. Вообще, полностью определенные пути рекомендуются. Таким образом только одна копия схемы будет иметь тенденцию существовать.

Отметьте, что невозможно использовать префиксы пространства имен, определяя расположения схемы. Объявление xsi:schemaLocation понимает только имена пространства имен и не префиксы.

Объявление Схем в Приложении

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

static final String employeeSchema = "employeeDatabase.xsd";
static final String taxSchema = "w2TaxForm.xsd";
static final String hiringSchema = "hiringForm.xsd";

static final String[] schemas = {
    employeeSchema,
    taxSchema, 
    hiringSchema,
};

static final String JAXP_SCHEMA_SOURCE =
    "http://java.sun.com/xml/jaxp/properties/schemaSource";

// ...

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance()
    
// ...

factory.setAttribute(JAXP_SCHEMA_SOURCE, schemas);

Здесь, массив строк, который указывает на определения схемы (файлы .xsd) передают как параметр методу factory.setAttribute. Отметьте различия от того, когда Вы объявляли, что схемы использовали в качестве части набора данных XML.

Нет никакого специального объявления для значения по умолчанию (неназванной) схемы.
Вы не определяете имя пространства имен. Вместо этого Вы только даете подсказки к файлам .xsd.

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

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

Строка, которая указывает на URI схемы
InputStream с содержанием схемы
SAX InputSource
Файл
Массив Объектов, каждый из которых является одним из типов, определенных здесь

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

Выполнение Выборки `DOMEcho` С Проверкой допустимости Схемы

Чтобы выполнить выборку DOMEcho с проверкой допустимости схемы, следуйте за шагами ниже.

Переместитесь к каталогу samples.% cd install-dir/jaxp-1_4_2-release-date/samples.
Скомпилируйте пример class, используя путь class, который Вы только что установили.% javac dom/*
Выполните программу DOMEcho на XML-файле, определяя проверку допустимости схемы.
Выберите один из XML-файлов в каталоге data и выполните программу DOMEcho на этом с определенной опцией -xsd. Здесь, мы хотели выполнять программу на файле personal-schema.xml.
% java dom/DOMEcho -xsd data/personal-schema.xml
Как Вы видели в Конфигурировании Фабрики, опция -xsd говорит DOMEcho выполнять проверку допустимости против XML-схемы, которая определяется в файле personal-schema.xml. В этом случае схема является файлом personal.xsd, который также располагается в каталоге sample/data.
Откройте personal-schema.xml в текстовом редакторе и удалите объявление схемы.
Удалите следование из вводного тега <personnel>.
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation='personal.xsd'
Не забывайте сохранить файл.
Выполните DOMEcho снова, определяя опцию -xsd еще раз.% java dom/DOMEcho -xsd data/personal-schema.xml
На сей раз Вы будете видеть поток ошибок.
Выполните DOMEcho еще раз, на сей раз определяя опцию -xsdss и определяя файл определения схемы.
Как Вы видели в Конфигурировании Фабрики, опция -xsdss говорит DOMEcho выполнять проверку допустимости против определения XML-схемы, которое определяется, когда программа выполняется. Еще раз используйте файл personal.xsd.
% java dom/DOMEcho -xsdss data/personal.xsd data/personal-schema.xml
Вы будете видеть тот же самый вывод как прежде, подразумевая, что XML-файл был успешно проверен против схемы.

«Предыдущий • След • Затем»