Создание IEPD NIEM: Часть 3. Расширение NIEM

Проектирование системы обмена XML-информацией между государственными учреждениями США

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

Присцилла Уолмсли, управляющий директор, Datypic

Фото Присциллы УолмслиПрисцилла Уолмсли (Priscilla Walmsley) работает управляющим директором и старшим консультантом компании Datypic. Она специализируется на технологии, архитектуре и реализации XML. В последнее время Присцилла работает с Министерством юстиции США (через Trusted Federal Systems) над системой IEPD LEXS нa базе NIEM. Она – автор книг Definitive XML Schema (Prentice Hall, 2001 г.) и XQuery (O'Reilly Media, 2007 г.). Кроме того, она является соавтором учебника Web Service Contract Design and Versioning for SOA (Prentice Hall, 2008 г.). С Присциллой можно связаться по адресу: pwalmsley@datypic.com.



10.02.2012 (Впервые опубликовано 09.03.2010)

18 мая 2010 г. В разделах "Введение", "Заключение" и "Ресурсы" добавлены ссылки на четвертую часть цикла.

12 мая 2010 г. Следуя комментариям читателей, автор изменил XML-схему в одном из загружаемых файлов. Из-за ошибки эта схема не работала.
В листинге 1 в конце строки 15 добавлено '/niem-core.xsd' так что теперь она выглядит следующим образом:

  <xsd:import schemaLocation="../../niem/niem-core/2.0/niem-core.xsd"

Кроме того, загружаемый файл niem3schemas.zip заменен новой версией.

Часто используемые сокращения

  • CMT: Component Mapping Template
  • IEPD: Information Exchange Package Documentation
  • NDR: NIEM Naming and Design Rules
  • NIEM: National Information Exchange Model
  • SSGT: NIEM Schema Subset Generation Tool
  • XML: Extensible Markup Language

Национальная модель обмена информацией (NIEM) велика – более 6000 элементов, – но, скорее всего, она не содержит всего того, что может понадобиться для XML-обмена. Она не может охватить все возможные сценарии и содержит лишь наиболее распространенные информационные строительные блоки. Для большинства создаваемых пакетов документации информационного обмена (IEPD) приходится составлять схему расширения, которая добавляет уникальные для данного случая типы и свойства. NIEM дает подробные рекомендации, как расширить модель таким образом, чтобы добиться максимальной совместимости между пакетами IEPD NIEM.

Более того, NIEM-модель не определяет конкретные типы или структуры сообщений для сборки всех объектов информационного обмена. Задача создателя IEPD – составить схему обмена, определив корневой элемент и базовую структуру сообщений.

В первой и второй частях этого цикла статей мы рассматривали простой пример заявления об угоне (см. ссылки на эти статьи в разделе Ресурсы). На рисунке 1 показана соответствующая модель обмена. Типы Bicycle и TheftReport, а также свойства IsRegistered, VehicleCategory и CountyCode не удалось отобразить на базовую модель NIEM. (См. текстовую версию рисунка 1.)

Рисунок 1. Модель IEPD с расширениями
Модель IEPD с расширениями

В данном случае NIEM отвечает большинству требований. Однако нужно создать две новые схемы:

  • схему расширения для определения типа Bicycle и свойств IsRegistered, VehicleCategory и CountyCode;
  • схему обмена для определения типа TheftReport (так как это корень) и построения структуры, которая позволит включать в сообщение все другие типы.

Создание схем NIEM

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

В дополнение к ограничениям, налагаемым языком XML Schema, NIEM добавляет собственные правила, которые описаны в документе NIEM Naming and Design Rules (NDR - см. ссылку в разделе Ресурсы). Эти правила охватывают, среди прочего, стандарты наименования и документирования компонентов NIEM, разрешенные и запрещенные виды конструкций XML-схемы и допустимые способы использования и расширения NIEM. Чтобы быть NIEM-совместимыми, схемы IEPD должны следовать правилам NDR.

Каждая схема должна иметь свое собственное целевое пространство имен. В нашем примере IEPD используется http://www.datypic.com/theftreport/extension/1.0 (с префиксом trext:) как пространство имен для схемы расширения и http://www.datypic.com/theftreport/exchange/1.0 (с префиксом tr:) для схемы обмена.

Использовать структуру каталогов, которая отражает пространство имен — обычная практика. Создадим внутри IEPD-заявления об угоне каталоги с именами extension и exchange, а внутри каждого из них – подкаталог с именем 1.0, в который поместим соответствующие документы схемы.

Начало типичного документа схемы NIEM – в данном случае расширения схемы для примера с заявлением об угоне – приведено в листинге 1.

Листинг 1. Начало NIEM-совместимой схемы
<xsd:schema targetNamespace="http://datypic.com/theftreport/extension/1.0"
            version="1.0"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:trext="http://datypic.com/theftreport/extension/1.0"
            xmlns:s="http://niem.gov/niem/structures/2.0"
            xmlns:nc="http://niem.gov/niem/niem-core/2.0"
            xmlns:niem-xsd="http://niem.gov/niem/proxy/xsd/2.0"
            xmlns:i="http://niem.gov/niem/appinfo/2.0">
  <xsd:annotation>
    <xsd:documentation>Theft Report extension schema</xsd:documentation>
    <xsd:appinfo>
      <i:ConformantIndicator>true</i:ConformantIndicator>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:import schemaLocation="../../niem/niem-core/2.0/niem-core.xsd"
              namespace="http://niem.gov/niem/niem-core/2.0"/>
  <xsd:import schemaLocation="../../niem/proxy/xsd/2.0/xsd.xsd"
              namespace="http://niem.gov/niem/proxy/xsd/2.0"/>
  <xsd:import schemaLocation="../../niem/structures/2.0/structures.xsd"
              namespace="http://niem.gov/niem/structures/2.0"/>
  <xsd:import schemaLocation="../../niem/appinfo/2.0/appinfo.xsd"
              namespace="http://niem.gov/niem/appinfo/2.0"/>

Документ схемы NIEM должен содержать элемент xsd:annotation с описанием (в элементе xsd:documentation) и признаком NIEM-совместимости (в элементе xsd:appinfo).

Как и любая схема, она объявляет и импортирует все пространства имен, необходимые для прямых ссылок. Кроме того, в последней строке листинга 1 импортируется схема appinfo, которая объявляет элементы, используемые внутри элемента xsd:appinfo.

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


Схемы расширения

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

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

Использование групп подстановки

Пожалуй, самый простой способ расширения NIEM – это использование групп подстановки, которые позволяют объявить собственный элемент и указать, что он может заменять элемент NIEM. Это означает, что этот элемент может появляться в любом месте, где допустим элемент NIEM. Этот метод можно использовать, когда в модели NIEM имеется семантически эквивалентный элемент, но он не вполне соответствует вашим потребностям. Например, в нашей модели есть свойство CountyCode, которое семантически эквивалентно абстрактному элементу NIEM nc:LocationCounty, который появляется в адресе. Два элемента группы подстановки, которые являются частью основной модели NIEM, уже существуют, но они не отвечают нашим потребностям: nc:LocationCountyCode использует другую кодовую таблицу, a nc:LocationCountyName предназначен для записи имени, а не кода. Объявим новый элемент trext:LocationCountyCode, который использует нашу кодовую таблицу.

Декларация элемента trext:LocationCountyCode показана в листинге 2. Чтобы указать, что это замена для nc:LocationCounty, воспользуемся атрибутом substitutionGroup.

Листинг 2. Декларация элемента trext:LocationCountyCode и связанных с ним типов
<xsd:element name="LocationCountyCode" type="trext:CountyCodeType"
             substitutionGroup="nc:LocationCounty">
 <xsd:annotation>
  <xsd:documentation>A county code.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:simpleType name="CountyCodeSimpleType">
 <xsd:annotation>
  <xsd:documentation>A data type for a county code.</xsd:documentation>
  <xsd:appinfo>
    <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
  </xsd:appinfo>
 </xsd:annotation>
 <xsd:restriction base="xsd:token">
  <xsd:enumeration value="A">
    <xsd:annotation>
     <xsd:documentation>Ascot County</xsd:documentation>
    </xsd:annotation>
  </xsd:enumeration>
  <xsd:enumeration value="B">
    <xsd:annotation>
     <xsd:documentation>Burke County</xsd:documentation>
    </xsd:annotation>
  </xsd:enumeration>
  <xsd:enumeration value="C">
    <xsd:annotation>
     <xsd:documentation>Cross County</xsd:documentation>
    </xsd:annotation>
  </xsd:enumeration>
 </xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="CountyCodeType">
 <xsd:annotation>
  <xsd:documentation>A data type for a county code.</xsd:documentation>
  <xsd:appinfo>
    <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
  </xsd:appinfo>
 </xsd:annotation>
 <xsd:simpleContent>
  <xsd:extension base="trext:CountyCodeSimpleType">
    <xsd:attributeGroup ref="s:SimpleObjectAttributeGroup"/>
  </xsd:extension>
 </xsd:simpleContent>
</xsd:complexType>

В листинге 2 показаны также два определения типов, которые поддерживают элемент trext:LocationCountyCode. Во-первых, для каждого значения кода определяется простой тип с элементами xsd:enumeration. Затем на основе простого типа определяется сложный тип. Сложный тип добавляет универсальные атрибуты, такие как s:id, которые допустимы во всех объектах NIEM через ссылку на s:SimpleObjectAttributeGroup.

Создание абсолютно новых типов

Еще один способ расширения NIEM заключается в создании абсолютно нового типа. В нашей модели тип Bicycle вообще не имеет эквивалента в модели NIEM, так что нужно создать новый элемент и соответствующий новый сложный тип. Всякий раз при добавлении нового типа нужно смотреть, не может ли он быть частным случаем существующего типа NIEM – например, nc:ActivityType, nc:PersonType или nc:ItemType. Для Bicycle возьмем за основу тип nc:ConveyanceType, поскольку это транспортные средства, к которым относится велосипед. К тому же nc:ConveyanceType уже имеет большинство свойств, которые нам понадобятся, например, серийный номер и описание.

Так же как и при использовании предыдущего метода расширения, нужно определить как новый элемент – trext:Bicycle, так и тип – trext:BicycleType. Эти определения приведены в листинге 3.

Листинг 3. Декларация элемента trext:Bicycle и соответствующего типа
<xsd:element name="Bicycle" type="trext:BicycleType">
 <xsd:annotation>
  <xsd:documentation>A bicycle.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:complexType name="BicycleType">
 <xsd:annotation>
  <xsd:documentation>A data type for a bicycle.</xsd:documentation>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:extension base="nc:ConveyanceType">
    <xsd:sequence>
     <xsd:element ref="trext:BicycleRegisteredIndicator" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

В определении типа trext:BicycleType указано, что он расширяет элемент nc:ConveyanceType. Отметим, что при создании действительно нового типа – т. е. не основанного на какой-либо концепции, уже имеющейся в NIEM, – нужно отталкиваться от s:ComplexObjectType, корня всех сложных типов в NIEM.

trext:BicycleType опирается на элемент trext:BicycleRegisteredIndicator, который нужно объявить отдельно. Все элементы, атрибуты и типы схем NIEM представляют собой глобальные компоненты верхнего уровня с уникальными именами. В листинге 4 приведена декларация элемента trext:BicycleRegisteredIndicator.

Листинг 4. Декларация элемента trext:BicycleRegisteredIndicator.
<xsd:element name="BicycleRegisteredIndicator" type="niem-xsd:boolean">
 <xsd:annotation>
  <xsd:documentation>Whether a bicycle is registered.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

В отличие от trext:LocationCountyCode, который имеет собственный тип кодовой таблицы, тип trext:BicycleRegisteredIndicator соответствует одному из встроенных типов XML-схемы, boolean. Однако вместо того чтобы присвоить ему встроенный тип xsd:boolean, воспользуемся типом niem-xsd:boolean. Этот сложный тип, определенный в "proxy"-схеме xsd.xsd, указывает, что элемент содержит значение xsd:boolean, но также допускает универсальные атрибуты NIEM, такие как s:id.

Добавление свойств к существующим типам

Другой вариант расширения – это сложный тип, который семантически эквивалентен типу NIEM, но его нужно как-то изменить или дополнить. В нашей модели класс MotorVehicle эквивалентен NIEM nc:VehicleType, но ему требуется дополнительное свойство VehicleCategoryCode. При выполнении отображения я рассматривала в качестве возможного кандидата nc:ItemCategoryText, но решила, что это слишком общее свойство. На самом деле свойство VehicleCategoryCode обеспечивает классификацию транспортных средств, используемую для целей налогообложения, поэтому я назвала элемент trext:VehicleTaxClassCode.

Требуемые определения XML-схемы аналогичны расширению Bicycle. В листинге 5 показано, как объявить новый элемент – trext:Vehicle и новый сложный тип – trext:VehicleType, который расширяет nc:VehicleType.

Листинг 5. Декларация элемента trext:Vehicle и соответствующего типа
<xsd:element name="Vehicle" type="trext:VehicleType">
 <xsd:annotation>
  <xsd:documentation>A motor vehicle.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:complexType name="VehicleType">
 <xsd:annotation>
  <xsd:documentation>A data type for a motor vehicle.</xsd:documentation>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:extension base="nc:VehicleType">
    <xsd:sequence>
     <xsd:element ref="trext:VehicleTaxClassCode" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Добавление новых объектов к существующим типам

Бывает, что типы NIEM подходят, но хочется использовать более конкретные или лучше подходящие для данного случая имена. Для своей модели я решила, что класс Theft соответствует типу NIEM nc:ActivityType. Однако мне не хотелось называть свой элемент nc:Activity, потому что это слишком общее и недостаточно описательное имя. Поэтому я решила объявить новый элемент trext:Theft, но присвоить ему существующий тип nc:ActivityType вместо того, чтобы определять новый. Декларация типа показана в листинге 6.

Листинг 6. Декларация элемента trext:Theft
<xsd:element name="Theft" type="nc:ActivityType">
 <xsd:annotation>
  <xsd:documentation>A theft incident.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

Схемы обмена

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

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

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

В примере заявления об угоне схема обмена будет содержать элемент tr:TheftReport, так как он корневой, и его тип. В нее войдет элемент TheftReportDate, который показан в модели. Но главное, – элемент tr:TheftReport, объединяющий все объекты и ассоциации, определенные для обмена. Элемент и тип TheftReport приведены в листинге 7.

Листинг 7. Декларация элемента trext:TheftReport и соответствующего типа
<xsd:element name="TheftReport" type="tr:TheftReportType">
 <xsd:annotation>
  <xsd:documentation>A theft report.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

<xsd:complexType name="TheftReportType">
 <xsd:annotation>
  <xsd:documentation>A data type for a theft report.</xsd:documentation>
  <xsd:appinfo>
    <i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
  </xsd:appinfo>
 </xsd:annotation>
 <xsd:complexContent>
  <xsd:extension base="s:ComplexObjectType">
    <xsd:sequence>
     <xsd:element ref="tr:TheftReportDate" minOccurs="1" maxOccurs="1"/>
     <xsd:element ref="trext:Theft" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="nc:ActivityConveyanceAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="trext:Vehicle" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="trext:Bicycle" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:ActivityLocationAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="nc:Location" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:ActivityVictimAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:Victim" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:ActivityWitnessAssociation"
                                    minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="j:Witness" minOccurs="0" maxOccurs="unbounded"/>
     <xsd:element ref="nc:Person" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:extension>
 </xsd:complexContent>
</xsd:complexType>

Обратите внимание, что все элементы объектов и ассоциаций родственны друг другу. Это типично для NIEM-сообщения, где связи между объектами – это отдельные компоненты, которые ссылаются на родственные объекты через атрибуты s:ref.

В листинге 8 приведен фрагмент сообщения, который показывает связь между угоном и местом происшествия. Объекты trext:Theft и nc:Location родственны друг другу, и у каждого есть атрибут s:id, который служит уникальным идентификатором. Ассоциация j:ActivityLocationAssociation – еще один "родственник", который связывает два объекта с использованием дочерних элементов с атрибутами s:ref.

Листинг 8. Пример ассоциации
<trext:Theft s:id="T1">
  <nc:ActivityDate>
      <nc:DateTime>2006-05-04T08:15:00</nc:DateTime>
  </nc:ActivityDate>
</trext:Theft>

<j:ActivityLocationAssociation>
   <nc:ActivityReference s:ref="T1"/>
   <nc:LocationReference s:ref="L1"/>
</j:ActivityLocationAssociation>

<nc:Location s:id="L1">
  <nc:LocationAddress>
   <nc:StructuredAddress>
     <nc:LocationStreet>
       <nc:StreetFullText>123 Main Street</nc:StreetFullText>
     </nc:LocationStreet>
     <nc:LocationCityName>Big City</nc:LocationCityName>
     <trext:LocationCountyCode>A</trext:LocationCountyCode>
     <nc:LocationStateUSPostalServiceCode>MI</nc:LocationStateUSPostalServiceCode>
     <nc:LocationPostalCode>49684</nc:LocationPostalCode>
   </nc:StructuredAddress>
  </nc:LocationAddress>
</nc:Location>

Другой способ выражения отношений между объектами – containment, когда один объект является родителем другого объекта. Например, гипотетически можно создать новый тип TheftType, содержащий имя пострадавшего и место происшествия или ссылку на то или другое. Однако с NIEM не рекомендуется использовать этот подход. Разделение ассоциаций дает более четкое разграничение объектов, уменьшает проблемы с рекурсией и лучше приспособлено к соотношениям типа "многие-ко-многим".


Именование и документирование компонентов NIEM

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

  • Имя содержит выражение объекта и выражение свойства, а если это простой элемент, то и выражение представления. В имени BicycleRegisteredIndicator, например, Bicycle – это выражение объекта, Registered – выражение свойства, а Indicator – выражение представления. Можно добавить также дополнительные выражения классификаторов.
  • Существует определенный набор утвержденных выражений представления, в число которых входят Indicator, Code, Date, Text, Value и Quantity.
  • Вместо разделителей все имена используют "горбатый" регистр (каждое слово начинается с прописной буквы).
  • Имена атрибутов начинаются со строчной буквы, а имена элементов и типов – с прописной.
  • Все типы в конце имени содержат слово Type.

Существуют также правила, регулирующие документацию NIEM-компонентов. У всех схем, элементов, атрибутов, типов и перечислений должны быть определения, которые начинаются с одного из утвержденных начальных выражений, таких как A name of или A relationship.

Это только несколько примеров правил NIEM, полный перечень которых приведен в NDR.


Редактирование подмножества

При построении схем расширения и обмена могут понадобиться дополнительные компоненты NIEM, еще не включенные в подмножество. Например, trext:BicycleRegisteredIndicator имеет тип niem-xsd:boolean, отсутствовавший в моем первоначальном подмножестве.

К счастью, подмножество легко отредактировать с помощью инструмента создания подмножеств схемы (Schema Subset Generation Tool – SSGT). На главной странице SSGT (см. ссылку в разделе Ресурсы) нажмите кнопку Options в верхнем правом углу. Она приведет на страницу, показанную на рисунке 2 (см. увеличенную версию рисунка 2.)

Рисунок 2. Страница Options SSGT
Страница Options SSGT

В разделе Load Wantlist укажите (или найдите) имя своего файла wantlist.xml, затем нажмите Load Want List. Ваше подмножество откроется на левой панели. Теперь можно нажать кнопку Search и воспользоваться правой панелью для поиска и добавления компонентов в подмножество NIEM. После этого регенерируйте подмножество.

Как регенерировать подмножество

Подробнее о том, как регенерировать подмножество, см. в разделе Генерирование подмножества NIEM второй части этого цикла статей.

При работе с расширениями иногда приходится использовать SSGT для поиска типов, а не свойств. Чтобы найти niem-xsd:boolean, нельзя использовать функцию поиска свойств по умолчанию, потому что она ищет только имена элементов и атрибутов, а не имена типов. Чтобы искать имена типов, выберите Types из раскрывающегося меню Search for a на странице поиска SSGT.


Документирование отображения в CMT

Обязательно задокументируйте свои расширения в шаблоне сопоставления компонентов (CMT), который описан во второй части настоящего цикла статей. Как минимум, нужно указать выражения XPath своих элементов расширения. В таблице 1 показаны заполненные расширения для классов MotorVehicle и Bicycle.

Таблица 1. Отображение XPath для расширений
Исходный типИсходное свойство...Расш.?XPath
MotorVehicle...Даtrext:Vehicle
MotorVehicleLicensePlate...Даtrext:Vehicle/ nc:ConveyanceRegistrationPlateIdentification/ nc:IdentificationID
MotorVehicleVehicleCategory...Даtrext:Vehicle/ trext:VehicleTaxClassCode
Bicycle...Даtrext:Bicycle
BicycleIsRegistered...Даtrext:Bicycle/ trext:BicycleRegisteredIndicator

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


Заключение

В этой статье описан процесс расширения NIEM. Объясняется роль схем расширения и обмена, показаны различные способы добавления новых элементов и типов на основе компонентов NIEM. Теперь большая часть работы по созданию IEPD NIEM проделана. В четвертой части мы рассмотрим последний и решающий шаг, сборку IEPD. Я познакомлю вас с различными артефактами, которые составляют IEPD. Результатом станет полный, NIEM-совместимый IEPD-заявления об угоне.


Загрузка

ОписаниеИмяРазмер
Component Mapping Template (CMT)niem3mapping.zip26 КБ
Схемы NIEM Exchange, Extension и Subsetniem3schemas.zip18 КБ

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML
ArticleID=792744
ArticleTitle=Создание IEPD NIEM: Часть 3. Расширение NIEM
publish-date=02102012