8 de janeiro de 2011

Criando Esquema para validar um XML - parte IV

A flexibilidade das especificações para um XML feitas através de XSD pode chegar ao ponto de garantirmos que o valor de um determinado elemento no XML está de acordo com uma máscara previamente projetada. Um bom exemplo disso é a formatação do código do produto, campo que usei nos outros posts sobre esse assunto. Muitas empresas usam uma formatação inteligente para o código do produto, isto é, partes do código ajudam a identificar e classificar o produto de modo que é imprescindível que ele esteja formatado corretamente.

A tag no XSD responsável por essa parametrização é a xs:pattern, inserida dentro da tag xs:restriction exatamente como as outras restrições apresentadas até agora. Em xs:pattern podemos especificar a série de valores aceitos na tag correspondente do XML, montando caracter a caracter a máscara desejada. Basicamente, a posição de um novo caracter é marcada com um par abre-e-fecha colchetes envolvendo os valores aceitos. O trecho abaixo, por exemplo, exige que o código seja formado por 3 letras maiúsculas :
<xs:element name="codigo" >
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z][A-Z][A-Z]" />
</xs:restriction>
</xs:simpleType>
</xs:element>

Veja que para especificar a faixa de caracteres aceitos em cada posição eu usei um hífen separando o caracter inicial e o final da faixa : A-Z. Se quiser permitir também que letras minúsculas e algarismos sejam aceitos, basta inserir as faixas correspondentes no mesmo par de colchetes. Na tag pattern abaixo, o código continua a ter obrigatoriamente 3 caracteres mas o primeiro deles pode ser uma letra maiúscula, uma minúscula ou um algarismo enquanto nas duas posições finais apenas letras maiúsculas continuam a ser permitidas:
<xs:pattern value="[A-Za-z0-9][A-Z][A-Z]" />

Não é necessário qualquer separador para delimitar as faixas pois, como cada par de colchetes representa apenas um caracter no texto, a separação entre elas fica implícita. Com a restrição publicada acima, os códigos aBC ou 9ER são válidos mas não AbC, por exemplo. Por causa disso, poderemos chegar ao ponto de especificar uma lista de caracteres aceitos numa determinada posição do nosso código. Suponha que nosso código tenha que ser iniciado com uma das seguintes letras : A, C, M ou P, indicando uma classificação qualquer do produto. Imagine também que o código seja finalizado com um dígito verificador, totalizando 4 caracteres. Segue abaixo a montagem dessa restrição no XSD:
<xs:pattern value="[ACMP][A-Z][A-Z][0-9X]" />

O dígito verificador nesse exemplo pode ser qualquer algarismo ou a letra X maiúscula. Note que o XSD não é capaz de garantir que o dígito verificador informado tenha sido calculado corretamente. Validações desse tipo já caracterizam regras de negócio específicas e não são abordadas pelo XSD. O objetivo dele se restringe a garantir que um XML baseado nele esteja minimamente bem construído. É o mesmo tipo de situação da Nota Fiscal Eletrônica, onde a Receita disponibiliza um XSD com o básico da formação do XML mas algumas consistências têm que ser feitas fora desse escopo, cruzando informações com outros sistemas - por exemplo, para verificar se o CNPJ do emissor está mesmo ativo.

Embora eu só tenha usado exemplos com letras e números, qualquer caracter pode fazer parte de uma restrição pattern - até mesmo o hifen (-) e o fecha colchete (]). No entanto, como esses caracteres têm significado especial na sintaxe do XSD, use uma barra (\) para indicar que você quer usar esse caracter como parte da regra de restrição. A regra reproduzida abaixo mostra o exemplo anterior modificado para que um hifen seja usado para separar o dígito verificador do resto do código:
<xs:pattern value="[ACMP][A-Z][A-Z][\-][0-9X]" />

A própria barra é um caracter especial e, para usá-la numa regra, ela terá que ser incluída dobrada. Os seguintes códigos são válidos segundo a restrição acima: AER-8, CUR-0 e PAR-X.

No próximo post, abordo outras regras aplicáveis à criação de restrições, como tratamento de caracteres em branco, lista de valores fixos válidos e como repetir padrões para simplificar a montagem de regras.

Mais Informações
Criando esquema para validar um xml - parte I, parte II e parte III, Tratamento de restrições no XSD

Nenhum comentário :

Postar um comentário

OBS: Os comentários enviados a este Blog são submetidos a moderação. Por isso, eles serão publicados somente após aprovação.

Observação: somente um membro deste blog pode postar um comentário.