Creating a NIEM IEPD, Part 3: Extend NIEM

Design an XML information exchange between U.S. government entities

Nos dois primeiros artigos desta série, você aprendeu a modular um intercâmbio NIEM, mapeá-lo para um modelo de base NIEM e criar um subconjunto do modelo NIEM para usar em sua IEPD. Agora, explore o que fazer com as partes de seu modelo que não são mapeadas diretamente para o NIEM, ao criar esquemas de extensão e intercâmbio para definir seus tipos e propriedades customizados.

Priscilla Walmsley, Managing Director, Datypic

Photo of Priscilla WalmsleyPriscilla Walmsley é Diretora de Gerenciamento e Consultora Senior na Datypic. Ela é especialista em tecnologias, arquitetura e implementação XML. Mais recentemente, ela trabalha (por meio do Trusted Federal Systems) com o Departamento de Justiça dos EUA na LEXS, uma estrutura IEPD baseada em NIEM. Ela é autora de Definitive XML Schema (Prentice Hall, 2001) e XQuery (O'Reilly Media, 2007). Ela também é coautora de Web Service Contract Design and Versioning for SOA (Prentice Hall, 2008). É possível entrar em contato com a Priscilla pelo e-mail pwalmsley@datypic.com.



04/Jun/2010 (Primeira publicação 04/Jun/2010)

12 de maio de 2010 - Como um acompanhamento para comentários de leitores, a autora alterou um documento do esquema XML em um arquivo de download. O erro torna o esquema inválido.
Na Listagem 1, adicionei '/niem-core.xsd' no final da linha 15 e agora se lê:

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

Também substituí o arquivo de download, niem3schemas.zip, com uma versão atualizada.

Acrônimos frequentemente usados

  • 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

O National Information Exchange Model (NIEM) é grande —mais de 6.000 elementos—, mas é muito provável que ele não contenha tudo que você gostaria de incluir em um intercâmbio XML. Ele não pretende cobrir todo cenário possível, mas, ao invés disso, os blocos de construção de informações mais comuns. Na maioria das Information Exchange Package Documentations (IEPDs) criadas, será necessário escrever um esquema de extensão que adiciona tipos e propriedades que são exclusivas de seu intercâmbio. O NIEM fornece diretrizes detalhadas para o modo de estender o modelo de uma maneira que maximiza a interoperabilidade entre IEPDs do NIEM.

O novo modelo NIEM também não define tipos de mensagem específicos ou estruturas para montar todos os objetos em um intercâmbio. Depende do criador da IEPD escrever um esquema de intercâmbio para declarar o elemento-raiz e a estrutura básica das mensagens.

Nas Partes 1 e 2 desta série, usei um exemplo simples de um Theft Report (consulte a seção de Recursos para obter os links para os dois artigos). A Figura 1 mostra o modelo que criei para meu intercâmbio. As propriedades e tipos que não fui capaz de mapear para o modelo NIEM base incluem os tipos Bicycle e TheftReport, além das propriedades IsRegistered, VehicleCategory, e CountyCode. (Consulte uma versão da Figure 1 somente em texto.)

Figura 1. Modelo IEPD mostrando extensões
IEPD model showing extensions

Neste caso, o NIEM satisfez a maioria das necessidades. Mas precisarei criar dois novos esquemas:

  • Um esquema de extensão para definir o tipo Bicycle e as propriedades IsRegistered, VehicleCategory e CountyCode
  • Um esquema de intercâmbio para definir o tipo TheftReport (pois essa é a raiz) e fornecer a estrutura que permite que todos os outros tipos sejam incluídos na mensagem.

Escrevendo esquemas NIEM

Esquemas de extensão e intercâmbio NIEM (assim como os esquemas do subconjunto gerado) são escritos no esquema XML. Este artigo mostra exemplos de esquemas em conformidade com o NIEM, mas não fornece uma explicação completa da linguagem de esquema XML. Se você é novo na área de esquemas, recomendo o XML Schema Primer (consulte a seção de Recursos) para uma introdução fácil.

Além das restrições impostas pelo esquema XML, o NIEM adiciona suas próprias regras que são documentadas no documento NIEM Naming and Design Rules (NDR) (consulte a seção de Recursos para obter um link). Essas regras cobrem, entre outras coisas, a nomeação e documentação de padrões para componentes NIEM, os tipos de construções de esquema XML que são permitidos e não permitidos e maneiras aprovadas de usar e estender o NIEM. Para estar em conformidade com o NIEM, os esquemas em uma IEPD devem seguir as regras NDR.

Cada documento de esquema deve possuir seu próprio espaço de nomes de destino. Para minha IEPD de exemplo, escolhi usar http://www.datypic.com/theftreport/extension/1.0 (com o prefixotrext:) como espaço de nomes para o esquema de extensão e http://www.datypic.com/theftreport/exchange/1.0 (com o prefixo tr:) para o esquema de intercâmbio.

É uma prática comum usar uma estrutura de pastas que reflita os nomes do espaço de nomes. Dentro da IEPD Theft Report, criarei pastas chamadas extension e exchange e, dentro de cada uma, uma subpasta chamada 1.0 na qual colocarei os respectivos documentos de esquema.

O início de um documento de esquema NIEM típico — neste caso, o esquema de extensão para o exemplo Theft Report — está na Listagem 1.

Listagem 1. Início de um esquema em conformidade com o 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"/>

Um documento de esquema NIEM deve conter um elemento xsd:annotation que possua uma descrição (em xsd:documentation) e um indicador que esteja em conformidade com o NIEM (em xsd:appinfo).

Assim como em qualquer esquema, ele declara e importa todos os espaços de nome que necessita referenciar diretamente. Também é necessário importar o esquema appinfo na última linha da Listagem 1, que declara os elementos usados dentro do elemento xsd:appinfo.

Observação: Documentos completos de esquema de extensão e intercâmbio que incluem todas as listagens neste artigo estão disponíveis na seção Downloads.


Esquemas de extensão

Dependendo da complexidade de sua IEPD, é possível ter um ou muitos esquemas de extensão. Alguns desenvolvedores de IEPD escolhem dividir esquemas de extensão em documentos múltiplos por área de assunto para permitir que eles reutilizem os esquemas de maneira mais granular em vários intercâmbios. Outros escolhem colocar componentes que possam ser atualizados mais frequentemente — por exemplo, listas de código — em um documento de esquema separado.

Para o exemplo Theft Report, por ser simples, escolhi criar um esquema de extensão. Após o início do esquema na Listagem 1, preciso definir tipos e declarar elementos para meus componentes customizados. Há várias maneiras de estender o NIEM e uso um método diferente para cada uma de minhas customizações.

Usando grupos de substituição

Talvez a maneira mais fácil de estender o NIEM seja através do uso de grupos de substituição, que permitem que você declare seu próprio elemento e especifique que ele seja substituível por um elemento NIEM. Isso significa que ele pode aparecer em qualquer lugar que o elemento NIEM seja permitido. É possível usar esse método quando houver um elemento semanticamente equivalente no modelo NIEM mas que não atenda realmente as suas necessidades. Por exemplo, em meu modelo, possuo uma propriedade CountyCode que é semanticamente equivalente ao elemento abstrato NIEM nc:LocationCounty que aparece dentro de um endereço. Já há dois elementos no grupo de substituição que fazem parte do modelo NIEM principal, mas eles não satisfazem as necessidades: nc:LocationCountyCode usa uma lista de código diferente e nc:LocationCountyName foi feito para um nome por extenso ao invés de um código. Ao invés disso, declarei um novo elemento trext:LocationCountyCode, que usa minha própria lista de códigos.

A Listagem 2 mostra a declaração de elemento para trext:LocationCountyCode. Para mostrar que é substituível por nc:LocationCounty, uso um atributo substitutionGroup.

Listagem 2. Declaração do elemento trext:LocationCountyCode e tipos relacionados
<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>

A Listagem 2 também mostra as definições de dois tipos que suportam o elemento trext:LocationCountyCode. Primeiro, um tipo simples que possui elementos xsd:enumeration para cada um dos valores de código é definido. Então, um tipo complexo é definido, baseando-se em um tipo simples. O tipo complexo adiciona atributos universais como s:id que são permitidos em todos os objetos NIEM através de uma referência a s:SimpleObjectAttributeGroup.

Criando tipos totalmente novos

Um outro método de extensão NIEM é criar um tipo completamente novo. Em meu modelo, Bicycle não possui, de maneira alguma, um equivalente no modelo NIEM, então, necessito criar um novo elemento e um novo tipo complexo correspondente. Sempre que adicionar um novo tipo, considere se ele é uma especialização de um tipo NIEM existente — por exemplo, nc:ActivityType, nc:PersonType ou nc:ItemType. Para Bicycle, decidi que ele deveria ser baseado em nc:ConveyanceType, pois ele representa um meio de transporte, que é adequado para uma bicicleta. Também, nc:ConveyanceType já possui a maioria das propriedades que necessito, como número de série e descrição.

Assim como no método de extensão anterior, tenho que definir tanto um novo elemento —trext:Bicycle— quanto um tipo —trext:BicycleType. A Listagem 3 mostra essas definições.

Listagem 3. Declaração do elemento trext:Bicycle e tipo relacionado
<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>

A definição de tipo para trext:BicycleType indica que ele estende nc:ConveyanceType. Observe que, se você estiver criando um tipo que seja realmente novo — ou seja, não baseado em nenhum conceito já existente no NIEM — é necessário basear seu tipo em s:ComplexObjectType, que é a raiz de todos os tipos complexos no NIEM.

Em trext:BicycleType, faço referência a um elemento trext:BicycleRegisteredIndicator que tenho que declarar separadamente. Todos os elementos, atributos e tipos nos esquemas NIEM são componentes globais, nomeados de maneira exclusiva, e de alto nível. A Listagem 4 mostra a declaração do elemento trext:BicycleRegisteredIndicator.

Listagem 4. Declaração do elemento 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>

Diferente de trext:LocationCountyCode, que possuía seu próprio tipo de lista de códigos, trext:BicycleRegisteredIndicator possui um tipo que corresponde a um dos tipos de esquema XML integrados boolean. No entanto, ao invés de dar a ele o tipo integrado xsd:boolean, uso niem-xsd:boolean. Esse tipo complexo, definido do esquema "proxy" xsd.xsd, especifica que o elemento contém um valorxsd:boolean, mas também permite os atributos NIEM universais como s:id.

Adicionando propriedades aos tipos existentes

Uma outra situação de extensão é onde você possui um tipo complexo que é semanticamente equivalente a um tipo NIEM, mas é necessário alterar ou adicioná-lo de alguma maneira. Em meu modelo, a classeMotorVehicle é equivalente ao nc:VehicleType do NIEM, mas necessita de uma propriedade extra, VehicleCategoryCode. Ao fazer o mapeamento, olhei para nc:ItemCategoryText como um possível candidato ao mapeamento, mas decidi que era muito geral. Na verdade, a propriedade VehicleCategoryCode representa uma classificação de veículos usados com propósito de taxas, então, decidi invocar o elemento trext:VehicleTaxClassCode.

As definições de esquema XML necessárias são similares à extensão Bicycle. A Listagem 5 mostra como declarei um novo elemento —trext:Vehicle— e um novo tipo complexo —trext:VehicleType— que estende nc:VehicleType.

Listagem 5. Declaração do elemento trext:Vehicle e tipo relacionado
<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>

Adicionando novos objetos com tipos existentes

Algumas vezes, você está feliz com os tipos NIEM, mas gostaria de usar nomes que fossem mais específicos ou relevantes para seu intercâmbio. Em meu modelo, decidi que a classe Theft corresponde ao nc:ActivityType do NIEM. No entanto, não estou completamente satisfeita invocando o elemento nc:Activity, pois ele é muito geral ou não é descritivo o suficiente. Neste caso, escolho declarar um novo elemento, chamado trext:Theft, mas lhe dar o tipo existente nc:ActivityType, ao invés de definir um novo tipo. A Listagem 6 mostra a declaração do elemento.

Listagem 6. Declaração do elemento trext:Theft
<xsd:element name="Theft" type="nc:ActivityType">
 <xsd:annotation>
  <xsd:documentation>A theft incident.</xsd:documentation>
 </xsd:annotation>
</xsd:element>

Esquemas de intercâmbio

Esquemas de intercâmbio contêm definições que são exclusivas para um tipo de mensagem ou grupo de tipos de mensagem. Geralmente, isso inclui somente o elemento-raiz e seu tipo e, possivelmente, alguns elementos estruturais que formam a estrutura básica da mensagem. Tipicamente, um esquema de intercâmbio é uma IEPD específica, enquanto que um esquema de extensão pode ser compartilhado em várias IEPDs.

Não é necessário possuir esquemas de intercâmbio e extensão separados; é possível colocar todas as suas extensões no mesmo documento de esquema. Também é possível possuir esquemas de intercâmbio múltiplos para representar diferentes tipos de mensagens ou grupos de tipos de mensagens diferentes.

Os esquemas de intercâmbio seguem todas as mesmas regras descritas anteriormente para esquemas de extensão. Por exemplo, eles devem possuir seu próprio espaço de nomes de destino e devem conter anotações.

No exemplo Theft Report, o esquema de intercâmbio irá conter o elemento tr:TheftReport, pois ele é a raiz e seu tipo. Ele irá conter um TheftReportDate, que é mostrado no modelo. Mas, o mais importante, o elemento tr:TheftReport será o que juntará todos os objetos e associações definidos no intercâmbio. O elemento e o tipo para TheftReport estão na Listagem 7.

Listagem 7. Declaração do elemento tr:TheftReport e tipo relacionado
<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>

Observe que os elementos do objeto e da associação são todos irmãos uns dos outros. Essa é uma típica mensagem NIEM, onde associações entre objetos são componentes separados que fazem referência aos objetos relacionados através de atributos s:ref.

Um fragmento de mensagem que mostra a associação entre um roubo e seu local está na Listagem 8. Os objetos trext:Theft e nc:Location são irmãos e cada um possui um atributo s:id dando a ele um identificador exclusivo. A associação, j:ActivityLocationAssociation, é um outro irmão que liga os dois objetos usando elementos filho com atributos s:ref.

Listagem 8. Instância de amostra mostrando associação
<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>

Uma outra opção para expressar relacionamentos entre objetos é a restrição, onde um objeto é o pai de um outro objeto. Por exemplo, é hipoteticamente possível criar um novíssimo TheftType que contenha em si uma pessoa e um local ou uma referência a uma pessoa ou a um local. No entanto, essa não é a abordagem recomendada para usar o NIEM. Associações separadoras tornam o delineamento de objetos mais claro, reduzem problemas com recursão e estão mais adaptadas a relacionamentos many-to-many.


Nomeando e documentando componentes NIEM

Você deve ter notado alguma consistência nos nomes usados nos exemplos. O NIEM impõe certas regras para nomes:

  • Um nome possui um termo de objeto e um termo de propriedade e se ele for um elemento simples, um termo de representação. Por exemplo, no nome BicycleRegisteredIndicator,Bicycle é o termo de objeto, Registered é o termo de propriedade e Indicator é o termo de representação. Também é possível que ele tenha termos qualificadores opcionais.
  • Há um conjunto específico de termos de representação aprovados, entre eles estão Indicator, Code, Date, Text, Value e Quantity.
  • Todos os nomes usam caixa alternante (primeira letra maiúscula em cada palavra) ao invés de caracteres separadores.
  • Nomes de atributos começam com uma letra minúscula, enquanto que nomes de elemento e tipo começam com uma letra maiúscula.
  • Todos os tipos possuem a palavra Type no final de seu nome.

Há também regras que governam a documentação de componentes NIEM. Todos os esquemas, elementos, atributos, tipos e enumerações devem possuir definições, e elas devem começar com uma frase de um conjunto de frases iniciais aprovadas, como A name of ou A relationship.

Isso é somente uma amostra das regras; é possível encontrar uma listagem completa das regras NIEM no NDR.


Modificando um subconjunto

Ao construir seus esquemas de extensão, talvez sejam necessários componentes adicionais do NIEM que não foram incluídos em seu subconjunto. Por exemplo, trext:BicycleRegisteredIndicator é do tipo niem-xsd:boolean, um tipo que não estava em meu subconjunto original.

Felizmente, é fácil modificar seu subconjunto usando o Schema Subset Generation Tool (SSGT). A partir da página principal do SSGT (consulte a seção de Recursos para obter um link), clique em Options no canto superior direito. Isso exibe a página na Figura 2. (Visualize uma versão ampliada da Figure 2.)

Figura 2. Página Options do SSGT
Screen capture of the SSGT Options page

Na seção chamada Load Wantlist, preencha (ou procure) seu nome de arquivo wantlist.xml e, então, clique em Load Want List. Ao fazer isso, seu subconjunto será exibido no painel do lado esquerdo. É possível, então, clicar em Search e usar o painel do lado direito para procurar e adicionar componentes ao seu subconjunto NIEM. Quando tiver concluído, gere o subconjunto novamente.

Como gerar um subconjunto novamente

Para detalhes sobre como gerar novamente um subconjunto, veja Gerando seu subconjunto NIEM na Parte 2 desta série de artigos.

Ao trabalhar com extensões, você, algumas vezes, gostaria de usar o SSGT para procurar tipos ao invés de propriedades. Para encontrar niem-xsd:boolean, não posso usar a pesquisa padrão para propriedades, pois ela encontra somente nomes de elementos e atributos, não nomes de tipo. Para procurar especificamente tipos, escolha Types no menu suspenso Search for a, na página de pesquisa do SSGT.


Documentando e mapeando no CMT

Certifique-se de documentar suas extensões no Component Mapping Template (CMT) que foi descrito na Parte 2 desta série de artigos. Preencha, no mínimo, as expressões XPath para seus elementos de extensão. A Tabela 1 mostra as extensões que preenchi para as classes MotorVehicle e Bicycle.

Tabela 1. Mapeamento XPath para extensões
Tipo de origemPropriedade de origem...Ext?XPath
MotorVehicle...Ytrext:Vehicle
MotorVehicleLicensePlate...Ytrext:Vehicle/ nc:ConveyanceRegistrationPlateIdentification/ nc:IdentificationID
MotorVehicleVehicleCategory...Ytrext:Vehicle/ trext:VehicleTaxClassCode
Bicycle...Ytrext:Bicycle
BicycleIsRegistered...Ytrext:Bicycle/ trext:BicycleRegisteredIndicator

Alguns novos profissionais do NIEM criam mais CMTs formais que possuem colunas separadas indicando o tipo de extensão, os tipos e elementos de base e o nível de alinhamento semântico. Para meu CMT, escolhi uma abordagem mais livre para definir as dependências incluindo essas informações em uma coluna Comments. O CMT Theft Report está disponível na área de Downloads.


Conclusão

Neste artigo, descrevi o processo de extensão do NIEM. Expliquei a função dos esquemas de extensão e intercâmbio e mostrei os vários métodos para adicionar novos elementos e tipos baseando-se em componentes NIEM. Agora, a maior parte do trabalho de criação de uma IEPD do NIEM está concluída. A Parte 4 descreverá a etapa final de montagem da IEPD. Mostrarei os vários artefatos que fazem parte de uma IEPD. O resultado será uma IEPD Theft Report completa, em conformidade com o NIEM.


Downloads

DescriçãoNomeTamanho
Component Mapping Template (CMT)niem3mapping.zip26KB
NIEM Exchange, Extension and Subset Schemasniem3schemas.zip18KB

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado
ArticleID=494471
ArticleTitle=Creating a NIEM IEPD, Part 3: Extend NIEM
publish-date=06042010