`elementFormDefault` иногда не работает - PullRequest
0 голосов
/ 17 февраля 2020

Введение

elementFormDefault="unqualified" для элемента <schema> устанавливает значение по умолчанию form="unqualified" для элементов, определенных в этой схеме.

Следующие действительные XML сегмент использовал схему, определенную с помощью elementFormDefault="unqualified"

<asnx:module xmlns:asnx="urn:ietf:params:xml:ns:asnx">
   <sequence/>
</asnx:module>

Элемент <sequence> не имеет квалификации пространства имен, поскольку схема была определена следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns="urn:ietf:params:xml:ns:asnx"
       targetNamespace="urn:ietf:params:xml:ns:asnx"
       elementFormDefault="unqualified">
....

Ненормальность

В определенной системе c, с которой я работаю, в описательной части данных XML использовался модульный X HTML, например:

<product:description>
 <xhtml:div>
  <xhtml:p>This product is discontinued</xhtml:p>
 </xhtml:div>
</product:description>

Из-за того, как программное приложение, над которым я работаю, было собрано, оно не будет работать, если не будет написано в следующей форме:

<product:description>
  <xhtml:div>
    <p>This product is discontinued</p>
  </xhtml:div>
</product:description>

То есть программное приложение не может обработать встроенный X HTML если элементы квалифицированы.

Я думал, что быстрое решение состоит в том, чтобы изменить схему для пространства имен X HTML, чтобы валидатор мог принимать внедренные элементы X HTML без оговорок. То есть изменить схему X HTML xhtml1-strict.xsd (только локально - система не будет обращаться к веб-сайту w3.org для получения официального файла xsd), изменив элемент root <schema> из elementFormDefault="qualified" до elementFormDefault="unqualified".

К моему удивлению, изменение не имеет эффекта. Валидатор (xmllint) по-прежнему требует <p> для уточнения:

элемент p: Ошибка достоверности схемы: Элемент 'p': Этот элемент не ожидается. Ожидается один из ({http://www.w3.org/1999/xhtml} p, {http://www.w3.org/1999/xhtml} div, {http://www.w3.org/1999/xhtml} fieldset, {http://www.w3.org/1999/xhtml} таблица, {http://www.w3.org/1999/xhtml} noscript, {http://www.w3.org/1999/xhtml} h1, {http://www.w3.org/1999/xhtml} h2, { http://www.w3.org/1999/xhtml} h3, {http://www.w3.org/1999/xhtml} h4, {http://www.w3.org/1999/xhtml} h5)

Исключено Возможные причины

Я подумал, что, возможно, я редактировал xhtml1-strict.xsd, не используемый системой, поэтому я отредактировал его части, например, изменив "div" на "vid" и наблюдая за возникшей ошибкой. Таким образом я проверил, что редактируемый файл - это файл, используемый валидатором.

Я также попытался изменить другие схемы, импортированные в пространство имен product, и убедился, что изменение elementFormDefault в любой импортированной схеме действительно иметь ожидаемый эффект на то, как валидатор требует, чтобы дочерний элемент был квалифицирован / неквалифицирован, и этот эффект явно отсутствует, когда я делаю то же самое с xhtml1-strict.xsd, поэтому в схеме x html есть что-то волшебное.

Ответы [ 2 ]

1 голос
/ 17 февраля 2020

У меня нет решения, но у меня теперь есть «ответ».

Во-первых, elementFormDefault не работает с элементами, определенными непосредственно в схеме, но только в подэлементах, определенных в элемент. В X HTML такие элементы, как <p>, не определяются как подэлементы <body>, а вместо этого являются самостоятельными элементами.

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

Я пришел к такому выводу во многих экспериментах. Я потратил много времени, пытаясь искать в определяющих документах напрасно.

Автор x html решил определить автономные элементы и сослаться на них, поэтому X HTML в его сущности не затрагивается elementFormDefault.

0 голосов
/ 17 февраля 2020

(Это комментарий к вашему ответу, но он слишком длинный для отправки в качестве комментария).

Отвечая на вопрос, что вы «потратили много времени на поиск в определяющих документах» - да, Трудно ориентироваться в спецификации W3 C XSD, но на самом деле довольно ясно, когда вы знаете, где искать и знать правильную терминологию.

Используя 1.0 spe c, раздел 3.3.2 имеет подпункт section «Если элемент информации <element> элемента имеет <schema> в качестве родителя, соответствующий компонент схемы выглядит следующим образом:« это говорит о том, что целевое пространство имен совпадает с пространством схемы.

Затем он имеет другой раздел » в противном случае, если элемент информации элемента <element> имеет <complexType> или <group> в качестве предка, а ref [attribute] отсутствует ", который говорит" Если форма присутствует и ее · фактическое значение · квалифицировано, или если форма отсутствует и · фактическое значение · elementFormDefault для <schema> предка квалифицируется, тогда [целевое пространство имен является] · фактическим значением · targetNamespace [атрибут ] информационного элемента родительского элемента <schema> или · отсутствует ·, если такового нет, в противном случае · отсутствует ·.

...