Noções básicas de lista de códigos

A Universal Business Language (UBL) define uma biblioteca, livre de royalties, de documentos XML eletrônicos de negócios padrão tais como ordens de compra e faturas. A UBL foi projetada para conectar diretamente a práticas existentes de negócios, jurídicas, de auditoria e de gerenciamento de registros. Ela ajuda a eliminar a reinserção de dados nas cadeias de fornecimento existentes baseadas em fax e papel, além do fornecimento de um ponto de entrada no comércio eletrônico para empresas de pequeno e médio porte.

Todos os documentos de negócios da UBL são definidos formalmente utilizando a linguagem XML Schema Definition (XSD) W3C e uma única coleção de componentes. Cada esquema define uma classe de documentos tais como uma ordem de fatura ou compra. Uma vez que a UBL é XML, as regras normais de XML também se aplicam a todos os documentos da UBL. Para informações introdutórias sobre UBL, leia o artigo do meu colega de trabalho (Consulte Recursos ).

Quando empresas trocam documentos de negócios em XML, é importante não apenas saber que se trata de um documento válido. Também é preciso verificar o valor de certos itens de informação tais como código do país, código de unidade monetária, formas de pagamento ou número de peça. As listas de códigos válidos de países e unidades monetárias são exemplos de listas de códigos gerenciadas internacionalmente, mas a lista de números de peças válidos de um fornecedor usada por um cliente em uma ordem de compra deve ser gerenciada localmente. Em geral, parceiros comerciais devem ser capazes de especificar restrições sobre valores e regras de negócios locais com facilidade e de forma simples, porém, declarativa.

Para um documento de negócios da UBL ser XML, ele deve, no mínimo, ser formatado corretamente. Isso significa que todos os elementos devem estar adequadamente aninhados. Por exemplo, <cbc:Party><cbc:PartyName> ... </cbc:PartyName></cbc:Party> está aninhado adequadamente, enquanto <cbc:Party><cbc:PartyName> ... </cbc:Party> </cbc:PartyName> não está. Você pode também verificar a estrutura e o léxico da instância, validando-o segundo o esquema. Por exemplo, se uma fatura UBL é identificada como uma instância da classe de documentos fatura, então ela é considerada válida.

A UBL fornece meios de um aplicativo verificar os valores de vários elementos e customizar essa verificação para as necessidades em especial de parceiros comerciais. Consulte Recursos para ler um artigo que apresenta a UBL.

Voltar para parte superior

Autoridades de lista de códigos— globais e locais

Listas de códigos são, às vezes, conhecidas como vocabulários controlados. O valor de um elemento deve ser um em uma lista finita de valores exclusivos padrão predefinidos. Quem deve ser a autoridade para manter esses valores?

Alguns valores têm escopo global (por exemplo, código do país) e devem ser gerenciados globalmente, enquanto outros têm apenas escopo local e devem ser gerenciados entre parceiros comerciais ou em uma comunidade de interesse (por exemplo, códigos de produtos do fornecedor). Esse tipo local de lista não tem qualquer relevância, em especial, fora da comunidade de interesse.

Por exemplo, um fornecedor de mercadorias pode manter uma lista de códigos de produtos padrão por meio da qual um cliente pode pedir um desses produtos fornecendo o código do produto adequado. Não podemos garantir a exclusividade desses códigos entre diferentes comunidades de interesse: o mesmo código de produto pode ser utilizado, descrevendo um produto completamente diferente em cada caso.

Estas são listas de códigos globais já gerenciadas por uma organização de normas internacionais. Elas incluem listas como códigos de unidades monetárias gerenciados pela organização internacional para normatização (ISO) (ISO 4217), códigos de país pela ISO (ISO 3166-1) e códigos de formas de pagamento pela United Nations Economic Commission for Europe (UNECE) (UNECE 4461). A UBL usa essas listas de códigos, sempre que elas existem, ao invés de reinventá-las.

É perfeitamente possível que uma comunidade de interesse exija apenas um subconjunto de uma lista de códigos ou que precise fornecer códigos adicionais atualmente não presentes na lista padrão. A UBL fornece suporte tanto para redução quanto para extensão da lista de códigos padrão para necessidades locais.

Voltar para parte superior

Os requisitos para listas de códigos

Na programação tradicional, a verificação de restrições estruturais, lexicais e de valor é responsabilidade de programas de aplicativos individuais. Para conseguir isso, é necessária uma equipe de programação e um processo para criação e manutenção de software.

Em uma implementação XML, a verificação estrutural e lexical foi padronizada e precede o aplicativo. Um documento XML deve estar no formato correto, e então será válido se, e somente se, estiver em conformidade com uma definição formal de esquema. Isso significa que a partir do momento em que um aplicativo recebe o documento, ele é dado como correto no que diz respeito à estrutura e ao léxico. Essa verificação pode ser realizada com componentes padrão.

Em aplicativos de negócios, com frequência é necessário verificar os valores de certos elementos da informação para determinar se eles são válidos. Como incorporamos essa verificação de valor em XML?

Uma forma é codificar os valores no esquema utilizando enumerações declaradas do esquema. Isso é feito normalmente por esquemas orientados a negócios, mas eles podem ser inflexíveis. Por exemplo, a listagem 1 é um fragmento dos códigos de unidades monetárias da Core Components Technical Specification (CCTS) da United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), atualmente utilizados nos esquemas da UBL 2.0. Eles estão sendo removidos nos esquemas da UBL 2.1 exatamente por serem inflexíveis.

<xsd:simpleType name="CurrencyCodeContentType">
      <xsd:restriction base="xsd:token">
      <xsd:enumeration value="AED">
        <xsd:annotation>
          <xsd:documentation>
            <ccts:CodeName>Dirham</ccts:CodeName>
            <ccts:CodeDescription></ccts:CodeDescription>
          </xsd:documentation>
        </xsd:annotation>
      </xsd:enumeration>
      <xsd:enumeration value="AFN">
        <xsd:annotation>
          <xsd:documentation>
            <ccts:CodeName>Afghani</ccts:CodeName>
            <ccts:CodeDescription></ccts:CodeDescription>
          </xsd:documentation>
        </xsd:annotation>
      </xsd:enumeration>
      <xsd:enumeration value="ALL">

      ...

    </xsd:restriction>
  </xsd:simpleType> 

Aqui, enumeramos todos os valores válidos possíveis que o CurrencyCodeContentType pode assumir. A anotação é usada para documentar o que significa o código.

Há apenas duas outras listas de códigos que foram implementadas como listas enumeradas no esquema UBL. Elas são identificadores de codificação MIME em BinaryObjectMimeCodeContentType e valores de código de unidade em UnitCodeContentType. As três enumerações são importadas de conjuntos de valores codificados padronizados pela UN/CEFACT e foram consideradas completas e suficientemente estáveis para incluir em uma enumeração até que requisitos de negócios para a UBL 2.1 revelaram que elas, na verdade, não são suficientemente estáveis.

Há um risco envolvido na alteração de um código quando ele está definido em uma lista enumerada em um esquema. Isso exige a modificação do esquema padrão para refletir essa alteração. Por exemplo, os códigos de países mudam com o tempo, como quando a Tchecoslováquia (código de país: CS) dividiu-se em dois países, República Tcheca (CZ) e Eslováquia (SK), e então o código de país CS foi reutilizado para Sérvia e Montenegro. Nesses casos, o aplicativo que recebe exige metadados em nível de instância, tais como um número de versão, para eliminar a ambiguidade do valor do código de país.

No caso de códigos de unidades monetárias, a lista de códigos, na ocasião do release da UBL 2.1, utilizou o valor TRY para a Lira turca, enquanto a lista de código na ocasião do release da UBL 2.0 utilizou o valor TRL para a mesma moeda. Um esquema UBL 2.1 deve validar todas as instâncias UBL 2.0. Se a UBL 2.1 continuasse a usar uma única enumeração para a unidade monetária, uma instância UBL 2.0 usando a Lira turca não seria validada. Embora construções com união estejam disponíveis para enumerações simples, a especificação CCTS para metadados associados de lista de códigos impede seu uso.

Essas simples situações de negócios do mundo real revelaram a desvantagem das enumerações baseadas em esquema para a manutenção de listas de códigos ao longo do tempo. A abordagem UBL 2.0 para listas de código de enumeração não baseada em esquema foi estendida na UBL 2.1 para todas as listas de códigos e as enumerações baseadas em esquema foram abandonadas por completo.

A enumeração em um esquema apresenta um problema para listas de códigos administradas localmente. Se uma lista de códigos local foi implementada como enumerações em um esquema, então o esquema padrão deve ser modificado para cada uso em especial do esquema, deixando-nos sem esquema padrão. Além disso, um item da informação definido globalmente pode ter conjuntos de valores diferentes em diferentes contextos de documentos. Um único conjunto enumerado não atenderia esse requisito.

A UBL tomou a abordagem exclusiva para implementar listas de códigos externas ao esquema para serem usadas em um processo de duas etapas, conforme mostrado na Figura 1. A validação estrutural e lexical é realizada de forma padronizada usando o esquema XSD. Por exemplo, uma fatura poderia ter sido construída em conformidade com UBL-Invoice-2.0.xsd. Caso seja válida, a instância é então validada segundo os valores. A UBL fornece um arquivo padrão UBL 2.0 defaultCodeList.xsl que pode ser usado neste estágio, mas o usuário final pode utilizar apenas um subconjunto destas listas, estendê-las ou adicionar listas de códigos novas. Se a instância é inválida nesta fase, ela é passada ao aplicativo para interpretação e processamento mais profundos. Isso dá aos usuários flexibilidade máxima na configuração e atualização das listas de códigos UBL, sem alterar os esquemas UBL padrão.

Necessidade de controle local

A UBL foi projetada para gerenciar documentos de negócios de maneira global. Se você examinar parceiros comerciais pelo mundo você encontrará uma infinidade de requisitos. Você também descobrirá que pode haver grandes diferenças entre os requisitos de um parceiro comercial e os de outro. Pode não haver qualquer padronização em um conjunto de valores representando conceitos de negócios que são específicos de parceiros comerciais. Parceiros comerciais necessitam especificar e implementar seus requisitos locais, mas globalmente é necessário manter tudo dentro do contexto da UBL.

Parceiros comerciais também precisam implementar regras de negócios. Por exemplo, um relacionamento de parceiros comerciais pode não permitir pedidos maiores que certa quantia monetária ou então cartões de crédito não podem ser utilizados para certos produtos. Novamente, parceiros precisam implementar regras de negócio, mas dentro do contexto da UBL. Schematron é uma forma de implementar essas regras de negócio (consulte Recursos para obter mais informações).

Voltar para parte superior

Uso de aplicativos das listas de códigos

Como um aplicativo pode implementar essa validação de duas fases dos documentos UBL?

Há uma coleção de ferramentas de software livre inovadoras que podem ser utilizadas para executar validações padrão de documentos UBL 2.0 incluídas no diretório val do pacote de release da UBL. As validações padrão assumem um sistema Linux ou Microsoft Windows® XP sem nenhum software de processamento XML ou XSLT instalado. Há também instâncias de teste incluindo um documento válido, um documento com o nome de um elemento grafado de forma incorreta e uma instância que é estrutural e lexicalmente válida, mas tem valores ilegais na lista de códigos. O pacote de release UBL 2.0 pode ser transferido por download como um único arquivo zip (consulte Recursos para obter um link).

A especificação de listas de códigos e a especificação da associação dessas listas a um documento UBL específico são realizadas via documentos XML. Listas de códigos são gerenciadas por genericode, enquanto os arquivos de associação são gerenciados por associações de contexto/valor (CVAs).

Genericode

O comitê Técnico de Representação da Lista de Códigos OASIS produziu o OASIS Genericode 1.0 que descreve o genericode como segue:

• Um modelo padrão e uma representação XML para os conteúdos de uma lista de códigos.
• Um modelo padrão e uma representação XML para dados associados com itens em uma lista de códigos.

Arquivos CVA permitem customização local entre parceiros comerciais. Algumas das ações que parceiros comerciais poderiam fazer com base em suas necessidades comerciais locais são:

• Incluir entidades de informações.
• Omitir entidades de informações opcionais.
• Refinar o significado de uma entidade de informações.
• Combinar ou recombinar e montar entidades de informações.
• Criar subconjuntos do modelo de documento — restringindo o número de entidades de informações em um documento.
• Restringir o conteúdo do documento — restringe os possíveis valores que uma entidade de informações pode assumir.
• Criar restrições sobre valores possíveis para entidades de informações tais como listas codificadas.
• Incluir regras de negócios.

Consulte a seção Recursos para um link que direciona a todo o conjunto de Diretrizes OASIS para realizar tais customizações. Se você consultar a Figura 1, verá que a validação do valor é realizada com um processo XSLT. Na UBL, a folha de estilo necessária para realização dessa tarefa é gerada programaticamente.

Como exemplo da maneira como uma lista de códigos pode ser definida, a listagem 2 é a mesma informação utilizada para a enumeração CurrencyCodeContentType (listagem 1, ), mas codificada como genericode.

<?xml version="1.0" encoding="ISO-8859-1"?>
<gc:CodeList xmlns:gc="http://genericode.org/2006/ns/CodeList/0.4/">
   <Identification>
      <ShortName>CurrencyCode</ShortName>
      <LongName xml:lang="en">Currency</LongName>
      <LongName Identifier="listID">ISO 4217 Alpha</LongName>
      <Version>2001</Version>
      <CanonicalUri>urn:un:unece:uncefact:codelist:specification:54217
</CanonicalUri>
      <CanonicalVersionUri>urn:un:unece:uncefact:codelist:specification:54217:2001
</CanonicalVersionUri>
      <LocationUri>http://docs.oasis-open.org/ubl/os-ubl-2.0/cl/gc/cefact
/CurrencyCode-2.0.gc</LocationUri>
      <Agency>
         <LongName xml:lang="en">United Nations Economic Commission for Europe
</LongName>
         <Identifier>6</Identifier>
      </Agency>
   </Identification>

   <ColumnSet>
      <Column Id="code" Use="required">
         <ShortName>Code</ShortName>
         <Data Type="normalizedString" xml:lang="en"/>
      </Column>
      <Column Id="name" Use="optional">
         <ShortName>Name</ShortName>
         <Data Type="string" xml:lang="en"/>
      </Column>
      <Key Id="codeKey">
         <ShortName>CodeKey</ShortName>
         <ColumnRef Ref="code"/>
      </Key>
   </ColumnSet>

<SimpleCodeList>
      <Row>
         <Value ColumnRef="code">
            <SimpleValue>AED</SimpleValue>
         </Value>
         <Value ColumnRef="name">
            <SimpleValue>Dirham</SimpleValue>
         </Value>
      </Row>
      <Row>
         <Value ColumnRef="code">
            <SimpleValue>AFN</SimpleValue>
         </Value>
         <Value ColumnRef="name">
            <SimpleValue>Afghani</SimpleValue>
         </Value>
      </Row>
      <Row>
         <Value ColumnRef="code">
            <SimpleValue>ALL</SimpleValue>
         </Value>
         <Value ColumnRef="name">
            <SimpleValue>Lek</SimpleValue>
         </Value>
      </Row>
 ....

Na listagem 2, Identification fornece alguns metadados sobre essa lista de códigos. ColumnSet define duas colunas, code e name, e indica que a coluna cujo ID é code pode ser utilizada como um valor-chave na lista de códigos. SimpleCodeList define então o conteúdo da lista de códigos no qual cada linha contém o valor do código e seu nome correspondente.

Observe que a definição desta lista de códigos é um documento XML. Ela possui um esquema W3C, o que significa que este arquivo de lista de códigos pode ser autorado e validado como qualquer outro arquivo XML.

Associação de Contexto/Valor (CVA)

O OASIS fornece uma especificação para um arquivo CVA padrão:

"Esta Especificação de Comitê 01 determina um vocabulário XML usado para expressar o relacionamento entre itens de informações encontrados em uma hierarquia estruturada (tais como a instância XML de um documento de negócios) e dois tipos de restrições impostos nestes itens. Um tipo de restrição é que o valor é membro de um conjunto de vocabulários controlados de valores enumerados (tais como listas de códigos ou identificadores). Outro tipo de restrição é uma avaliação arbitrária de uma expressão de consulta booleana (tal como uma verificação de valor de lista de códigos não numerável (digamos, o cálculo da soma de verificação de um número ISBN), uma regra de negócios ou uma restrição léxica sobreposta, tal como um tamanho máximo de valor de sequência)." (Veja o link para a Especificação de Comitê 01 OASIS em Recursos).

A Listagem 3 é um fragmento de código de um arquivo CVA para ilustrar os vários recursos de um arquivo CVA para PaymentMeansCode. Observe que ele é um arquivo XML com um esquema, então ele pode ser autorado e validado como qualquer outro arquivo XML. Nesse arquivo, associamos as várias ocorrências do PaymentMeansCode em um documento UBL com a lista de códigos correta para validar seu valor.

<?xml version="1.0" encoding="UTF-8"?>
<cva:ContextValueAssociation xmlns:cva="http://docs.oasis-open.org/codelist/ns
/ContextValueAssociation/1.0/"
                             xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd
:CommonBasicComponents-2"
                             xmlns:x="http://www.w3.org/1999/xhtml"
                             name="UBL-QualifiedDataTypes-2.0"
                             version="2010-08-30 20:21:05(UTC)"
                             id="urn:oasis:names:specification:ubl:cva:UBL-Qualified
-Data-Types:2">
   <Annotation>
      <Description>
         <x:p>
        This describes all of the qualified supplementary components and 
        business information entities for the OASIS Universal Business
        Language (UBL) 2.0 vocabulary.
      </x:p>

         <x:p>
        In UBL 2.1 qualified data types are anonymous (in that they are
        not expressly named or identified) and UBL information items with
        qualifications are addressed in this document and associated with
        their respective value qualifications.
      </x:p>
         <x:p>
        At this time all value qualifications are Code Lists, which are
        a type of value list (the other type being identifier lists).
        Instance metadata for UBL is described by the UN/CEFACT Core Component
        Technical Specification (CCTS) Version 2.01.
        The document contexts are all of the supplementary components and
        business entities in a UBL instance that have qualified values.
      </x:p>
      </Description>

   </Annotation>
   <Title>
    UBL 2.0 and UBL 2.1 qualified information items
  </Title>
   <ValueLists>
      <Annotation>
         <Description>

            <x:p>
          These list all of the genericode files of Code Lists used by
          UBL information items whose values are qualified by Code Lists.
        </x:p>
            <x:p>
          The unique identifier <x:samp>xml:id=</x:samp> is used later in
          this file when describing the context for each entity that has
          a qualified value.
        </x:p>

            <x:p>
          The URI value points to the genericode file associated with the 
          identifier. The URI is hyperlinked in this report to a rendering
          of the contents of the genericode file that follows the rendering
          of the contexts.
        </x:p>
         </Description>
      </Annotation>

     ...
 
     <ValueList xml:id="PaymentMeans-2.0"
                 uri="../../os-UBL-2.0/cl/gc/default/PaymentMeansCode-2.0.gc"/>

      <ValueList xml:id="PaymentMeans-2.1"
                 uri="../cl/gc/default/PaymentMeansCode-2.1.gc"/>

	...
 
 </ValueLists>
 <Contexts>
	<Annotation>
         <Description>

            <x:p>
          The contexts in which various items with a qualified value
          are specified.  
        </x:p>
            <x:p>
          The <x:samp>address=</x:samp> attribute is an XPath address that
          satisfies all of the UBL items in the instance that are qualified
          with the indicated value lists using the indicated associated set
          of instance-level metadata items.
        </x:p>

            <x:p>
          Each context identifies the collection of supplementary components 
          (by its identifier) where instance-level metadata is found, then
          all value lists (by their identifier) that apply to the item being
          addressed.
        </x:p>
            <x:p>
          The contexts are listed first for attribute items and then for
          element items.
        </x:p>
         </Description>

      </Annotation>
        
        ...

      <Context values="PaymentMeans-2.0 PaymentMeans-2.1"
               metadata="cctsV2.01-code"
               address="cbc:PaymentMeansCode"/>
        ...

        <Context values="Currency-2.0 Currency-2.1"
               metadata="cctsV2.01-code"
               address="cbc:DocumentCurrencyCode | 
                        cbc:TaxCurrencyCode | 
                        cbc:PricingCurrencyCode | 
                        cbc:PaymentCurrencyCode | 
                        cbc:PaymentAlternativeCurrencyCode | 
                        cbc:RequestedInvoiceCurrencyCode | 
                        cbc:SourceCurrencyCode | 
                        cbc:TargetCurrencyCode | 
                        cbc:CurrencyCode"/>
        ...

     </Contexts>
</cva:ContextValueAssociation>

Observe que, na seção ValueLists , há duas entradas para PaymentMeans, cada uma com um número de versão diferente (2.0 e 2.1). Isso permite uma referência para informações baseadas nas versões da UBL.

Na lista de contexto para o PaymentMeansCode, o Xpath cbc:PaymentMeansCode significa que essa referência é para o PaymentMeansCode onde quer que ele apareça no documento UBL (tanto no 2.0 quanto no2.1).

É possível referir-se a localizações específicas no documento UBL ou a múltiplas localizações. Por exemplo, vimos o caso da unidade monetária. Ela é associada com a união de vários códigos de unidades monetárias (DocumentCurrencyCode e TaxCurrencyCode).

A lista de códigos real para PaymentMeansCode, mostrada na listagem 4, também é especificada em um arquivo genericode. (Consulte Recursos).

<?xml version="1.0" encoding="UTF-8"?>
<gc:CodeList xmlns:gc="http://docs.oasis-open.org/codelist/ns/genericode/1.0/">
   <Identification>
      <ShortName>PaymentMeansCode</ShortName>
      <LongName xml:lang="en">Payment Means</LongName>
      <LongName Identifier="listID">UN/ECE 4461</LongName>
      <Version>D03A</Version>
      <CanonicalUri>urn:oasis:names:specification:ubl:codelist:gc:
PaymentMeansCode</CanonicalUri>
      <CanonicalVersionUri>urn:oasis:names:specification:ubl:codelist:gc:
PaymentMeansCode-2.0-update</CanonicalVersionUri>
      <LocationUri>http://docs.oasis-open.org/ubl/os-UBL-2.0-update/cl/gc
/default/PaymentMeansCode-2.0.gc</LocationUri>
      <Agency>
         <LongName xml:lang="en">United Nations Economic Commission for 
Europe</LongName>
         <Identifier>6</Identifier>
      </Agency>
   </Identification>
   
<ColumnSet>
      <Column Id="code" Use="required">
         <ShortName>Code</ShortName>
         <Data Type="normalizedString"/>
      </Column>
      <Column Id="name" Use="optional">
         <ShortName>Name</ShortName>
         <Data Type="string"/>
      </Column>
      <Key Id="codeKey">
         <ShortName>CodeKey</ShortName>
         <ColumnRef Ref="code"/>
      </Key>
   </ColumnSet>
   <SimpleCodeList>
      <Row>
         <Value ColumnRef="code">
            <SimpleValue>1</SimpleValue>
         </Value>
         <Value ColumnRef="name">
            <SimpleValue>Instrument not defined</SimpleValue>
         </Value>
      </Row>
      <Row>
         <Value ColumnRef="code">
            <SimpleValue>2</SimpleValue>
         </Value>
         <Value ColumnRef="name">
            <SimpleValue>Automated clearing house credit</SimpleValue>
         </Value>
      </Row>
    ...

      <Row>
         <Value ColumnRef="code">
            <SimpleValue>20</SimpleValue>
         </Value>
         <Value ColumnRef="name">
            <SimpleValue>Cheque</SimpleValue>
         </Value>
      </Row>

    ...

   </SimpleCodeList>
</gc:CodeList>

Se você examinar esta lista em detalhes, irá encontrar uma ampla array de formas de pagamento. Uma vez que a UBL foi projetada para ser utilizada globalmente, tanto para comércio local quanto internacional, ela deve cobrir todos os requisitos de negócios possíveis. Novamente, é possível reduzir essa lista a subconjuntos para atender requisitos de negócios locais. Nem todo mundo se sente a vontade com esses arquivos de sinal de maior e menor. Felizmente, eles são todos arquivos XML, o que significa que podemos utilizar XLST para transformá-los em HTML, ou utilizar XSL-FO para transformá-los em arquivo formais para impressão ou PDF (consulte Recursos).

Por exemplo, utilizando uma folha de estilo XSLT, você poderia transformar o arquivo genericode acima em um relatório HTML legível que lista todos os elementos XML, atributos e valores, juntamente com os arquivos XML associados, tais como as listas de códigos. Para ver a saída HTML dessa transformação para o arquivo genericode acima, veja a entrada "Contextos" em Recursos. Neste relatório, você verá que o PaymentMeansCode mostra-se como na listagem 5.

address="cbc:PaymentMeansCode"

instance metadata set: cctsV2.01-code
value list: PaymentMeans-2.0 (detail)
value list: PaymentMeans-2.1 (detail)

cctsV2.01-code, PaymentMeans-2.0, PaymentMeans-2.1e(detail) são links para as partes adequadas do relatório, permitindo rápida exploração de relatórios. E mais adiante, dentro do relatório, há uma tabela HTML detalhando as 100 formas de se realizar um pagamento na UBL. A folha de estilo utilizada pelo comitê para criar esse relatório é um download grátis da Crane Softwrights Ltd. (Consulte Recursos

Voltar para parte superior

Gerando a Folha de Estilo XSLT da Fase 2

Conforme mencionado anteriormente, a folha de estilo utilizada na validação de valores da fase 2 é gerada programaticamente. Na figura 2, a folha de estilo de validação de asserção (2) pode ser construída a partir das associações de contexto/valor (CVA), das expressões de lista de valores externos (GC) e das regras de negócios (SCH). Todos esses são documentos XML padrão e podem ser processados via software de processamento de XML padrão. Na verdade, podemos gerar uma folha de estilo XLST padrão que, ao ser processada contra um documento XML, pode determinar que o conteúdo do documento é válido e atende às regras de negócio.

Na figura 2, há três tipos de entradas representando as necessidades dos parceiros comerciais:

1. Associações de contexto/valor (3), expressas em genericode, permitem validação do valor com base no contexto de uma entidade de informações no documento XML de origem. A entidade de informações específica é expressa via uma expressão Xpath.
2. Expressões de lista de valores externos (4), expressas em genericode, os vocabulários controlados
3. Regras de Negócios (5), expressas em Schematron

Voltar para parte superior

Regras de Negócios

Muitos parceiros comerciais gostariam de estabelecer condições locais que devem permanecer verdadeiras em situações específicas. Essas são as regras de negócios que se aplicam para estes parceiros comerciais específicos.

Na UBL, isso pode ser especificado através de uma implementação Schematron ISO/IEC 19757-3. Um arquivo Schematron é simplesmente um conjunto de asserções sobre um documento UBL que pode ser testado em termos de validade. O Schematron é expresso utilizando um vocabulário Schematron XML. (Consulte Recursos para obter links para maiores informações sobre Schematron).

Schematron é implementado normalmente utilizando XSLT, embora haja uma implementação Python disponível. Com a implementação XSLT, a folha de estilo XSLT utilizada na validação de valor da segunda fase é gerada programaticamente utilizando os arquivos genericode, arquivos CVA e arquivos Schematron. Essa folha de estilo gerada, quando aplicada contra um documento UBL válido, irá relatar quaisquer erros de valores no arquivo UBL.

Voltar para parte superior

conclusão

Você concluiu uma visão geral introdutória dos elementos das listas de códigos em documentos XML utilizando a OASIS UBL como vocabulário e implementação de exemplos. A validação do documento UBL inclui não apenas a validação estrutural e lexical do documento UBL utilizando W3C XSD, mas também a verificação de valor de conteúdo de vários elementos de informações no documento. Embora os pacotes de release UBL contenham as listas de códigos padrão que podem ser utilizadas, a tecnologia da lista de código fornece recursos e diretrizes para permitir que os parceiros comerciais customizem essas listas codificadas para suas necessidades locais específicas e implementem regras de negócios como uma camada sobre isso. Embora tenhamos ilustrado as tecnologias de lista de códigos com UBL, elas podem ser utilizadas em diversos domínios com qualquer documento XML, em especial documentos XML comerciais, dos quais a UBL é apenas um exemplo. O Ministro da Educação da Nova Zelândia e o FpXML são dois exemplos do uso de tecnologias de lista de códigos.

Recursos

Aprender

• UBL and Disruptive Innovation: Out-of-the-box business XML for multiple industries (Hugh Chatfield, developerWorks, novembro de 2010): Leia o artigo do colega de trabalho para uma explicação ou uma boa introdução a UBL, seu valor na criação de documentos comerciais, alguns exemplos do seu uso e uma explicação de porque esta é uma inovação disruptiva.
  
  
• UBL 2 Guidelines for Customization, First Edition:Encontre o conjunto completo de Diretrizes OASIS para customização.
  
  
• Context/value association using genericode 1.0: Committee Specification 1.0: Leia a especificação OASIS completa para associações de contexto/valor.
  
  
• A Hands-on introduction to Schematron (Uche Ogbuji, developerWorks, setembro de 2004): Leia este artigo para uma boa visão geral do Schematron.
  
  
• OASIS Universal Business Language (UBL) Technical Committee
  
  
• OASIS Code List Representation Technical Committee
  
  
• Currency Code List: Veja o esquema para CurrencyCodeContentType incluindo os valores da lista de códigos.
  
  
• Appendix E. UBL 2.0 Code Lists and Two-phase Validation (Informative): Leia uma breve introdução à validação UBL de duas fases.
  
  
• CVA file — HTML rendition: Esta é a versão HTML padrão dos itens de informações qualificados da UBL 2.0 e UBL 2.1.
  
  
• CVA for UBL: O arquivo CVA completo para UBL.
  
  
• Genericode implementations: Revise uma lista de implementações conhecidas de genericode.
  
  
• UBL FAQ: Aprenda a partir das perguntas mais frequentes para UBL.
  
  
• PaymentMeansCode: Encontre a lista de códigos completa para PaymentMeansCode especificada em um arquivo genericode.
  
  
• Contexts: Saiba mais com um exemplo de um arquivo XML transformado em HTML.
  
  
• CCTS (2003) — Core Components Technical Specification — Part 8 of the ebXML Framework: Revise informações para servirem de guia na interpretação ou implementação de conceitos ebXML.
  
  
• Cover Pages: Saiba mais sobre a UBL na Cover Pages, uma abrangente coleção de referência on-line que suporta a família XML dos padrões de linguagens de marcações.
  
  
• Crane Softwrights— UBL 2.0 Model Summary Reports: Acesse conjuntos de 61 arquivos HTML (cada um com aproximadamente 3MB comprimidos) resumindo os itens de informações e planilhas de modelo de documento. A Crane Softwrights Ltd. é uma consultoria fornecendo Análise de Sistemas de Computador e serviços de treinamento em todo mundo desde abril de 1997.
  
  
• OASIS UBL TC — UBL 2 Guidelines for Customization: Acesse orientação prática na criação de esquemas de documentos compatíveis e em conformidade com UBL.
  
  
• OASIS(2006) — UBL 2.0 — sample UBL documents: Saiba mais a partir destes exemplos de documentos UBL tais como fatura, ordem e resposta da ordem.
  
  
• Zona de Segmentos de Mercado do IBM developerWorks: Consulte o site de Segmentos de Mercado para obter os recursos técnicos mais recentes específicos para os segmentos de mercado voltados para desenvolvedores.
  
  
• Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
  
  
• Eventos técnicos e webcasts do developerWorks : Permaneça atualizado com os webcasts e eventos técnicos do developerWorks.
  
  

Obter produtos e tecnologias

• Software de avaliação da IBM : Inove seu próximo projeto de desenvolvimento de software livre com o software de avaliação IBM, disponível para download ou em DVD.
  
  

Discutir

• Blogs do developerWorks : Participe da comunidade do developerWorks.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Noções básicas de lista de códigos
• Autoridades de lista de códigos globais e locais
• Os requisitos para listas de códigos
• Uso de aplicativos das listas de códigos
• Gerando a Folha de Estilo XSLT da Fase 2
• Regras de Negócios
• conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais