4.4 Получение сложных типов посредством ограничений

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

Предположим следующее. Мы хотим модифицировать наше определение списка items в международном счете на покупку так, чтобы он мог содержать, по крайней мере, один item . Схема, показанная в ipo.xsd, позволяет элемент items представить без каких-либо дочерних  элементов item. Чтобы создавать новый тип ConfirmedItems, мы определяем его обычным образом. Для этого указываем, что он получен посредством ограничения от исходного типа Items, и обеспечиваем новое (с более сильным ограничением) значение для минимального количества появляющихся элементов item. Обратите внимание. Типы, которые включаются в наследуемый тип, получаемый посредством ограничения, должны повторять все компоненты определения исходного типа:

Получение ConfirmedItems посредством ограничения Items

<complexType name=”ConfirmedItems”>
 <complexContent>
  <restriction base=”ipo:Items”>
   <sequence>

    <!-- item element is different than in Items -->
    <element name=”item” minOccurs=”1” maxOccurs=”unbounded”>

     <!-- remainder of definition is same as Items -->
     <complexType>
      <sequence>
       <element name=”productName” type=”string”/>
       <element name=”quantity”>
        <simpleType>
         <restriction base=”positiveInteger”>
          <maxExclusive value=”100”/>
         </restriction>
        </simpleType>
       </element>
       <element name=”USPrice” type=”decimal”/>
       <element ref=”ipo:comment” minOccurs=”0”/>
       <element name=”shipDate” type=”date” minOccurs=”0”/>
      </sequence>
      <attribute name=”partNum” type=”ipo:SKU” use=”required”/>
     </complexType>
    </element>

   </sequence>
  </restriction>
 </complexContent>
</complexType>

Выполненное изменение требует, по крайней мере, одного дочернего элемента. Тем самым сужается допустимое количество дочерних элементов от минимума, равного 0, к минимуму, равному 1. Это более предпочтительно по сравнению с допущением ни одного, либо несколько дочерних элементов. Отметим, что все элементы типа ConfirmedItems также будут приемлемы как элементы типа Item.

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

Таблица 3. Примеры ограничений

Основа

Ограничение

Замечания

 

default="1"

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

 

fixed="100"

задание фиксированного значения, в случае когда ничего предварительно не было определено

 

type="string"

задание типа в случае, когда ничего предварительно не было определено

(minOccurs, maxOccurs)

(minOccurs, maxOccurs)

 

(0, 1)

(0, 0)

исключение дополнительной компоненты; это может также быть достигнуто, опуская объявление при ограничении определения типа

(0, unbounded)

(0, 0) (0, 37)

 

(1, 9)

(1, 8) (2, 9) (4, 7) (3, 3)

 

(1, unbounded)

(1, 12) (3, unbounded) (6, 6)

 

(1, 1)

-

не может ограничить minOccurs или maxOccurs

 

Сайт создан в системе uCoz