XML Schema Part 0 Primer Second Edition

(em Português)

Status do documento traduzido

Esta é uma tradução da recomendação XML Schema Part 0 Primer Second Edition do W3C, cuja versão original poderá ser encontrada em:

http://www.w3.org/TR/xmlschema-0/

Notas acerca da tradução

Alerta-se aqui para o facto desta tradução poder conter erros, próprios e inerentes a cada tradução deste tipo. Certo tipo de conceitos são difíceis de traduzir para o Português, ou deveriam ainda ser contemplados com uma explicação mais plausível. Em todo o caso, tentou-se aqui uma aproximação exacta ao contexto original.


Tradutor : Alexandre Cláudio de Sena Viegas (contacto: Bandlos17@hotmail.com, hospedado em http://desenaviegas.com/)

Data da tradução : 03 de Maio de 2005


W3C

Esquema XML, Parte 0: Princípios Básicos, 2ª. Edição

Recomendação do W3C, de 28 de Outubro de 2004

Esta versão:
http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/
Última versão:
http://www.w3.org/TR/xmlschema-0/
Versão anterior:
http://www.w3.org/TR/2004/PER-xmlschema-0-20040318/
Editores:
David C. Fallside, da IBM
Priscilla Walmsley - 2ª. Edição

Por favor, consulte a errata deste documento, a qual poderá conter eventuais correcções normativas.

Este documento também está disponível nos seguintes formatos (não-normativos): XMLXHTML, com uma visível mudança do markup. Veja também as respectivas traduções.


Resumo

Esquema XML, Parte 0: Princípios Básicos é um documento não-normativo, com o qual se pretende fornecer uma descrição de fácil leitura das facilidades relacionadas com o Esquema XML, e é orientado no sentido de uma rápida compreensão da forma como se criam as linguagens dos referidos esquemas. Esquema XML, Parte 1: Estruturas e Esquema XML, Parte 2: Tipos de dados fornecem a descrição normativa da linguagem referente ao Esquema XML por completo. Este documento descreve as características da liguagem através de numerosos exemplos, os quais são ainda complementados pelas extensivas referências aos textos normativos.

Estatuto deste Documento

Esta secção descreve o estatuto do documento pela altura da sua publicação. Ele poderá vir a ser ultrapassado e substituído por outros documentos. A lista com as actuais publicações do W3C e com as mais recentes revisões deste relatório técnico poderão ser encontradas no Índex dos relatórios técnicos do W3C em http://www.w3.org/TR/.

Esta é uma Recomendação do W3C, a primeira parte da 2a. Edição do Esquema XML. Este documento foi revisto pelos Membros do W3C, bem como por outras partes nele interessadas, tendo sido endossado pelo Director na qualidade de Recomendação do W3C. Ele provém de fontes fidedignas e poderá ser utilizado como material de referência. O W3C tem por objectivos, ao elaborar esta Recomendação, a chamada de atenção para esta especificação e ainda promover e divulgar a sua distribuição. Essa acção realça a funcionabilidade e a inter-operacionabilidade da Web.

Este documento foi produzido pelo Grupo de Trabalho do W3C responsável pelo Esquema XML como parte da Actividade XML do W3C. Os objectivos pretendidos no uso da linguagem do Esquema XML são discutidos no documento Requesitos do Esquema XML. Os autores deste documento são membros pertencentes ao Grupo de Trabalho do W3C responsável pelo Esquema XML. As diferentes partes desta especificação foram elaboradas por vários editores.

Este documento foi produzido de acordo com a Práticas Actuais das Patentes, de 24 de Janeiro de 2002 (CPP) segundo a emenda estabelecida pelo Procedimento de Transição da Política das Patentes do W3C. O Grupo de Trabalho mantém uma lista pública com as divulgações das patentes, a qual é relevante para este documento; essa página inclui ainda instruções que explicitam a divulgação das patentes. Um indivíduo que possua o actual conhecimento de uma patente, a qual ele acredite conter as indicações essenciais respeitantes a estas especificações, deverá divulgar essa informação, de acordo com a secção 6 da Política das Patentes do W3C.

A versão desta especificação em Inglês é a única versão normativa. As informações referentes às traduções deste documento estão disponíveis em http://www.w3.org/2001/05/xmlschema-translations.

Esta 2a. edição não é em realidade nenhuma nova versão, ela incorpora apenas as alterações ditadas pelas correcções dos erros encontrados na 1a. edição segundo acordado pelo Grupo de Trabalho responsável pelo Esquema XML, como sendo o mais conveniente para os demais leitores. Uma lista em separado, contendo todas essas correcções, poderá ser encontrada em http://www.w3.org/2001/05/xmlschema-errata.

A lista da errata para esta 2ª. Edição está disponível em http://www.w3.org/2004/03/xmlschema-errata.

Por favor, relate-nos qualquer erro encontrado neste documento, através do endereço electrónico www-xml-schema-comments@w3.org (arquivo).

Tabela referente aos Conteúdos

1 Introdução
2 Conceitos Básicos: A Ordem de Aquisição
    2.1 Esquema da Ordem de Aquisição
    2.2 Definições dos Tipos Complexos, Declarações dos Elementos e dos Atributos
    2.3 Tipos Simples
    2.4 Definições do Tipo Anónimo
    2.5 Índice dos Elementos
    2.6 Anotações
    2.7 Modelos da Construção dos Conteúdos
    2.8 Grupos de Atributos
    2.9 Valores Nil
3 Conceitos Avançados I: Espaços-nominais, Esquemas & Qualificações
    3.1 Espaços-nominais Alvo & Locais não qualificados
    3.2 Locais Qualificados
    3.3 Declarações Globais e Locais
    3.4 Espaços-nominais Alvo não declarados
4 Conceitos Avançados II: Ordem de Aquisição Internacional
    4.1 Um Esquema em Múltiplos Documentos>
    4.2 Derivando Tipos por Extensão
    4.3 Utilizando os Tipos Derivados nos Documentos de Instância
    4.4 Derivando os Tipos Complexos por Restrição
    4.5 Redefinindo os Tipos e os Grupos
    4.6 Grupos de Substituição
    4.7 Elementose Tipos Abstractos
    4.8 Controlando o Uso e a Criação dos Tipos Derivados
5 Conceitos Avançados III: O Relatório Trimestral
    5.1 Especificando as Singularidades
    5.2 Definindo as Teclas-chave e as suas Referências
    5.3 Restrições do Esquema XML (x) Atributos ID do XML 1.0
    5.4 Importando Tipos
    5.5 Qualquer Elemento, Qualquer Atributo
    5.6 Localização do Esquema
    5.7 Conformidades

Apêndices

A Agradecimentos
B Os Tipos Simples e as suas Facetas
C Utilizando as Entidades
D Expressões Regulares
E Índex
    E.1 Elementos do Esquema XML
    E.2 Atributos do Esquema XML


1 Introdução

Este documento fornece uma fácil descrição aproximada da linguagem de definição do Esquema XML e deverá ser usado em paralelo com as descrições formais da linguagem contida nas Partes 1 e 2, correspondentes à especificação do Esquema XML. A audiência para a qual este documento se destina, inclui os programadores das aplicações, em cujos programas sejam lidos e escritos os documentos contendo esquemas, e autores de esquemas que necessitem de aprofundar mais os seus conhecimentos respeitantes a este tipo de linguagem, especialmente as características que forneçam uma funcionabilidade que vá para além da funcinabilidade fornecida pelas DTDs (Definição do Tipo de Documento). Parte-se do princípio que você possuia conhecimentos básicos relacionados com o XML 1.0 e os Espaços-nominais em XML. Cada uma das secções principais aqui presentes introduzirá novas características da linguagem, descrevendo-as contextualmente através de exemplos concretos.

Conceitos Básicos: A Ordem de Aquisição (§2) obedece aos mecanismos básicos do Esquema XML. Ela descreve a forma como se devem declarar os elementos e os atributos que aparecem nos documentos XML, bem como as distinções entre os tipos simples e os tipos complexos. Ela define ainda os tipos complexos, o uso dos tipos simples para os valores do elemento e do atributo, as anotações referentes ao esquema, um mecanismo simples de re-utilização dos elementos e definições dos atributos, bem como os valores “nil”.

Conceitos Avançados I: Espaços-nominais, Esquemas e sua Qualificação (§3), a primeira secção principal deste documento explica os princípios básicos, através dos quais os espaços-nominais são utilizados em XML e nos documentos com esquemas. Esta secção é importante para a compreensão da maioria dos tópicos que aparecem nas outras secções principais com os conceitos avançados.

Conceitos Avançados II: A Ordem de Aquisição Internacional (§4), a segunda secção principal deste documento, contendo os princípios avançados, descreve os mecanismos para a derivação dos tipos já existentes, bem como controlo dessas derivações. Esta secção descreve também os mecanismos utilizados para fundir os fragmentos de um esquema, os quais provenham de várias fontes, bem como para a substituição de elementos.

Conceitos Avançados III: O Relatório Trimestral (§5) prevê a maioria das características mais avançadas, incluindo as que são destinadas à especificação das singularidades existentes entre os atributos e os elementos, um mecanismo destinado ao uso do tipos ao longo dos espaços-nominais, um mecanismo destinado aos tipos extensíveis, baseado nos espaços-nominais e uma descrição detalhada da forma como a conformidade dos documentos é verificada.

A somar às secções que acabaram de ser descritas, este documento contém um número de apêndices que fornecem informações detalhadas referentes ao tipos simples e às expressões regulares da linguagem.

Este é um documento não-normativo, o que significa que ele não fornece (segundo o ponto de vista do W3C) especificações definitivas referentes à linguagem do Esquema XML. Os exemplos, bem como outros exemplos explicativos contidos neste documento, são aqui fornecidos com o intuito de o ajudar a compreender o Esquema XML, se bem que eles nem sempre forneçam respostas efectivas. Em tais casos, você necessitará de se referir à especificação do Esquema XML e, para ajudá-lo a realizar tal tarefa, nós fornecer-lhe-emos várias ligações (links), apontando para as partes mais relevantes desta especificação. Específicamente, os itens relacionados com o Esquema XML, mencionados neste documento estão ligados ao index [Index (§E)] referente aos nomes dos elementos e dos atributos, e a um sumário descrevendo os tipos de dados. O Quadro com o sumário e o Índex contêm links para as secções mais relevantes das partes 1 e 2 do Esquema XML.

2 Conceitos Básicos: A Ordem de Aquisição

A finalidade de um esquema é a de definir uma classe de documentos XML, de forma que o termo “documento de instância” é frequentemente utilizado para descrever um documento XML que esteja em conformidade com um esquema em particular. De facto, nem as instâncias nem os esquemas necessitam de existir na qualidade de documentos per se -- eles podem existir como fluxos de bits, enviados entre as aplicações, como campos de registro numa base de dados, ou como colecções dos “Itens de Informação” dos Infosets XML – mas, a fim de simplificar estes fundamentos, nós escolhemos referir as instâncias e os esquemas como se tratassem eles de documentos ou de ficheiros.

Comecemos pois, considerando um documento contido num ficheiro, chamado po.xml. Ele descreve uma nota de encomenda, emitida para a encomenda de produtos caseiros e sua respectiva facturação:

A nota de encomenda consiste num elemento principal, a Nota de Encomenda, e nos sub-elementos shipTo(enviar para), billTo (cobrar a), comment (comentário), e itens. Estes sub-elementos (à excepção do comentário) contêm por sua vez outros sub-elements, e por aí adiante, sendo de considerar ainda que sub-elementos como USPrice (preço praticado nos USA), contêm um número em vez de conter outros sub-elementos. Elementos que contenham outros sub-elementos ou transportem determinado tipo de atributos são considerados como possuindo um tipo complexo, ao passo que os elementos que contenham números (ou ainda strings, datas, etc.) e não outros sub-elementos quaisquer, são considerados como possuindo um tipo simples. Alguns elementos têm atributos; os atributos têm sempre um tipo simples.

Os tipos complexos nos documentos de instância, bem como alguns dos tipos simples, são definidos no esquema destinado às notas de encomenda. Os restantes tipos simples são definidos como parte do reportório dos tipos simples pré-definidos do Esquema XML.

Antes de continuarmos aqui a examinar o esquema correspondente à nota de encomenda, nós iremos aqui antes mencionar resumidamente a relação entre o documentos de instância e o esquema da nota de encomenda. Como você próprio poderá concluir, através da análise do documento de instância, o esquema da nota de encomenda não é mencionado. Em realidade, não é necessário que um documento de instância faça qualquer tipo de referências ao esquema, e se bem que muitos assim o façam, nós escolhemos manter esta 1ª. secção no seu estado simples e partir do princípio de que qualquer processador do documento de instância pode obter o esquema da nota de encomenda, sem que esta possua qualquer informação adicional do documento de instância. Em secções posteriores, nós iremos explicar os mecanismos de associação dos esquemas e dos documentos de instância.

next sub-section2.1 O Esquema da Nota de Encomenda

O esquema da nota de encomenda está contido no ficheiro po.xsd:

Exemplo
O Esquema da Nota de Encomenda
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <xsd:annotation>
    <xsd:documentation xml:lang="en">
     Esquema da Nota de Encomenda Example.com. Copyright 2000 Example.com.      Todos os direitos são reservados!
    </xsd:documentation>
  </xsd:annotation>

  <xsd:element name="purchaseOrder" type="PurchaseOrderType"/>

  <xsd:element name="comment" type="xsd:string"/>

  <xsd:complexType name="PurchaseOrderType">
    <xsd:sequence>
      <xsd:element name="shipTo" type="USAddress"/>
      <xsd:element name="billTo" type="USAddress"/>
      <xsd:element ref="comment" minOccurs="0"/>
      <xsd:element name="items"  type="Items"/>
    </xsd:sequence>
    <xsd:attribute name="orderDate" type="xsd:date"/>
  </xsd:complexType>

  <xsd:complexType name="USAddress">
    <xsd:sequence>
      <xsd:element name="name"   type="xsd:string"/>
      <xsd:element name="street" type="xsd:string"/>
      <xsd:element name="city"   type="xsd:string"/>
      <xsd:element name="state"  type="xsd:string"/>
      <xsd:element name="zip"    type="xsd:decimal"/>
    </xsd:sequence>
    <xsd:attribute name="country" type="xsd:NMTOKEN"
                   fixed="US"/>
  </xsd:complexType>

  <xsd:complexType name="Items">
    <xsd:sequence>
      <xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="productName" type="xsd:string"/>
            <xsd:element name="quantity">
              <xsd:simpleType>
                <xsd:restriction base="xsd:positiveInteger">
                  <xsd:maxExclusive value="100"/>
                </xsd:restriction>
              </xsd:simpleType>
            </xsd:element>
            <xsd:element name="USPrice"  type="xsd:decimal"/>
            <xsd:element ref="comment"   minOccurs="0"/>
            <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
          </xsd:sequence>
          <xsd:attribute name="partNum" type="SKU" use="required"/>
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
  </xsd:complexType>

  <!-- Stock Keeping Unit, a code for identifying products -->
  <xsd:simpleType name="SKU">
    <xsd:restriction base="xsd:string">
      <xsd:pattern value="\d{3}-[A-Z]{2}"/>
    </xsd:restriction>
  </xsd:simpleType>

</xsd:schema>

O esquema da nota de encomenda consiste nos elementos do esquema e numa variedade de sub-elementos, os elementos de maior destaque, do Tipo complexo, e do Tipo simples, os quais determinam a aparência e o conteúdo dos elementos nos documentos de instância.

Cada um dos elementos contidos nesse esquema tem um prefixo do tipo xsd:, o qual está associado com o espaço-nominal do Esquema XML [namespace], através da declaração xmlns:xsd="http://www.w3.org/2001/XMLSchema", que aparece no elemento esquema. O prefixo xsd: é utilizado por convenção para denotar os espaços-nominais do Esquema XML, se bem que se possa utilizar qualquer outro prefixo. O mesmo prefixo, e portanto a mesma associação, aparecem também nos nomes dos tipos simples pré-definidos, por exemplo xsd:string. O propósito desta associação é identificar os elementos e os tipos simples, como pertencentes ao vocabulário da linguagem do Esquema XML e não tanto ao vocabulário do autor do esquema. De acordo com uma maior claridade no texto, nós mencionamos aqui apenas os nomes dos elementos e dos tipos simples (ex: Tipo simples), tendo omitido o seu prefixo.

previous sub-section next sub-section2.2 Definições de Tipos Complexos, Declaração dos Elementos e dos Atributos

No Esquema XML, existe uma diferença básica entre os tipos complexos, os quais permitem elementos no seu conteúdo, podendo ainda ter atributos e os tipos simples, os quais não podem ter elementos no seu conteúdo ou possuir qualquer tipo de atributos. Existe também uma grande distinção entre as definições que criam novos tipos (tanto simples como complexos), e declarações que permitam que os elementos e atributos com nomes e tipos específicos (quer sejam simples ou complexos) apareçam nas instâncias do documento. Nesta secção, nós focamos a atenção na definição dos tipos complexos e na declaração dos atributos que neles aparecem.

Os tipos complexos novos, são definidos usando o elemento Tipo complexo, sendo de denotar ainda que tais definições contêm típicamente um conjunto de declarações e referências dos elementos, bem como as declarações dos atributos. As declarações não são própriamente tipos, mas sim uma associação entre o nome e as restrições que regulam a aparência do mesmo nome nos documentos regulados pelo esquema associado. Os elementos declaram-se, utilizando o elemento element, e os atributos são declarados usando o elemento attribute. Por examplo, o USAddress (endereço USA) é definido como sendo um tipo complexo. Dentro da definição do USAddress, nós podemos ver cinco declarações de elementos e uma declaração de atributos:

Como consequência desta definição, qualquer elemento que apareça numa instância cujo tipo seja igual ao do USAddress (ex: shipTo(enviar para) no po.xml) deverá ser constituído por 5 elementos e 1 atributo. Esses elementos são, nomeadamente, o nome, a rua, a cidade, o Estado e o Código Postal, como o especificado pelos valores dos atributos das declarações do nome, e os elementos devem aparecer na mesma sequência pela qual eles são declarados. Os primeiros quatro elementos contêm cada um uma “string”, e o quinto elemento contém um número. Os elementos do tipo USAddress, poderão aparecer com um atributo denominado de país, o qual deverá conter a string US.

A definição USAddress contém apenas declarações envolvendo os tipos simples: string, decimal e NMTOKEN. Contrastando com o acima referido, a definição do Tipo:Nota de Encomenda contém declarações de elementos, envolvendo tipos complexos,como por exemplo USAddress, embora seja de destacar que ambas as declarações utilizam o mesmo tipo de atributo para identificar o tipo, não interessando aqui se o tipo é simples ou complexo.

Ao definir o Tipo: Nota de Encomenda, duas das respectivas declarações dos elementos, para shipTo (enviar para) e billTo (cobrar a), associam diferentes nomes de elementos contendo o mesmo tipo complexo, nomeadamente USAddress. Tendo como consequência desta definição, qualquer que seja o elemento que apareça num documento de instância (ex: po.xml), cujo tipo seja declarado como sendo Tipo:Nota de Encomenda, deverá ser constituído pelos elementos shipTo (enviar a) e billTo (cobrar a), cada um contendo os cinco sub-elementos (nome, rua, cidade, Estado e Código Postal), os quais foram declarados como parte integrante do USAddress (endereço USA). Os elementos shipTo (enviar a) e billTo (cobrar a) poderão ainda conter o atributo do país, o qual foi também declarado como parte do USAddress (endereço USA).

As definições do Tipo: Nota de Encomenda contêm a declaração do atributo orderDate (data de encomenda), bem como a declaração do atributo referente ao país, identificando-a na qualidade de tipo simples. De facto, todas as declarações referentes aos atributos dever-se-ão referir aos tipos simples, ao contrário das declarações dos elementos, uma vez que os atributos não poderão conter outros elementos ou atributos.

Cada uma das declarações dos elementos que nós descrevemos até aqui tem um nome associado a um tipo de definição existente. Por vezes é preferível utilizar um elemento já existente, em vez de se daclarar um novo elemento, como por exemplo:

Exemplo
<xsd:element ref="comment" minOccurs="0"/>

Esta declaração referencia um elemento já existente, [comment (comentário)], o qual foi declarado algures no esquema da nota de encomenda. Em geral, o valor do atributo ref deverá referir-se a um elemento global, ou seja, um elemento que já tenha sido declarado sob a referência do [schema (esquema)] e não como parte de uma definição do tipo complexo. A consequência desta declaração é a de que o elemento intitulado de [comment (comentário)] poderá aparecer num documento de instância e o seu conteúdo deve ser coerente com esse tipo de elemento, que neste caso se intitula de [string].

2.2.1 Restrições da Ocorrência

O uso do elemento [comment (comentário)] é opcional na [Nota de Encomenda], dado que o valor do atributo [minOccurs] corresponde na sua declaração a 0. Em geral, requer-se a presença de um elemento, quando o valor do [minOccurs] fôr maior ou igual a 1. O número máximo de vezes que um elemento poderá aparecer é determinado pelo valor do atributo [maxOccurs], na sua declaração. Esse valor pode ser um número inteiro, como por exemplo 41, ou o termo [unbounded (sem limite)], para indicar que não existe um número máximo de ocorrências. O valor atribuído por defeito para ambos os atributos, [minOccurs] e [maxOccurs] é igual a 1. Assim, quando um elemento do tipo [comment (comentário)] fôr declarado sem um atributo [maxOccurs], o elemento não poderá aparecer mais do que uma vez. Assegure-se de que você especificou o valor apenas para o atributo [minOccurs], o qual deverá ser menor ou igual ao valor estabelecido por defeito do atributo [maxOccurs], o que à letra significa 0 ou 1. De igual forma, se você especificar um valor apenas para o atributo [maxOccurs], ele deverá ser maior ou igual ao valor atribuído por defeito do atributo [minOccurs], o que à letra significa que ele deverá ser maior ou igual a 1. Se ambos os atributos forem omitidos, o elemento deve aparecer apenas uma vez.

Os atributos podem aparecer uma vez ou nenhuma, e mais nenhum outro número de vezes, de forma que a síntaxe utilizada para especificar as ocorrências dos atributos é diferente da síntaxe destinada aos elementos. Em particular, os atributos podeem ser declarados com um atributo do tipo [use (uso)], para indicar se o atributo é o não requirido (veja por exemplo, a declaração do atributo [partNum] em [po.xsd]), [optional (opcional)], ou até mesmo [prohibited (proibido].

Os valores atribuídos por defeito dos elementos e dos atributos são declarados utilizando o atributo [default], embora este atributo tenha uma consequência diferente para cada caso. Quando um atributo é declarado com um valor por defeito, o valor do atributo é o mesmo que nos é indicado no documento de instância; se o atributo não for indicado no dodcumento de instância, o processador do esquema iguala o atributo ao valor do atributo por default. Note que os valores atribuídos por defeito só fazem sentido se os próprios atributos forem opcionais, pelo que será considerada como errada, a especificação de um valor por defeito ou ainda qualquer outro que não o valor [optional (opcional)] para o atributo use.

O processador dos esquemas trata os elementos aos quais foram aplicados os valores por defeito de uma forma um pouco diferente. Quando um elemento é declarado com um valor por defeito, o valor do elemento é um qualquer valor que apareça como conteúdo do documento num documento de instância; se o documento for apresentado sem qualquer conteúdo, o processador de esquemas provirá o elemento com um valor igual ao do considerado pelo atributo default. Contudo, se o elemento não aparecer no documento de instância, o processador de esquemas não atribuirá qualquer valor ao elemento. Resumindo, as diferenças entre o tratamento dos elementos e dos atributos por defeito são: Os valores por defeito dos atributos só são aplicados quando os atributos não forem apresentados, e os valores por defeito dos elementos só são aplicados quando os elementos estiverem vazios, sem conteúdo.

O atributo [fixed (fixo)] é utilizado em ambas as declarações, na dos atributos e na dos elementos, de forma a assegurar que os atributos e os elementos sejam igualados a valores específicos. Por exemplo, po.xsd , contém uma declaração para o atributo country, o qual é declarado com o atributo fixed, com um valor equivalente a US. Esta declaração significa que a aparecimento do atributo [country (país)] num documento de instância é optional (o valor por defeito do atributo use é opcional), embora no caso do atributo aparecer, o seu valor tenha de ser US e, se o atributo não aparecer, o processador de esquemas fornecerá um atributo [country (país)], contendo o valor US. Note que os conceitos de valor fixo e valor estabelecido por defeito são mútuamente exclusivos, sendo portanto assim um erro se a declaração contiver ambos os atributos, [fixed (fixo)] e [default (defeito].

Os valores dos atributos utilizados nas declarações do elemento e do atributo, com o fim de limitar as suas ocorrências, são sumariados no Quadro 1.

Quadro 1. Restrições de Ocorrência para os Elementos e Atributos
Elementos
(minOccurs, maxOccurs)
fixed, default
Atributos
use, fixed, default
Notas
(1, 1) -, - são requeridos, -, - elemento/atributo deve aparecer uma vez, podendo ter qualquer valor
(1, 1) 37, - são requeridos, 37, - elemento/atributo deve aparecer uma vez, o seu valor deverá ser 37
(2, unbounded) 37, - n/a o elemento deve aparecer duas ou mais vezes, o seu valor deverá ser 37; em geral, os valores minOccurs e maxOccurs deverão ser números inteeiros positivos, devendo ainda o valor maxOccurs ser [“unbounded” (ilimitado)]
(0, 1) -, - opcional, -, - o elemento/atributo poderá aparecer uma vez e assumir qualquer valor
(0, 1) 37, - n/a o elemento pode aparecer uma vez, mas se ele não aparecer tal não será necessário; se ele não aparecer e estiver vazio, o seu valor é 37; se ele aparecer e não estiver vazio, o seu valor deverá ser 37
n/a opcional, 37, - o atributo pode aparecer uma vez, se ele aparecer valor deverá ser 37, se não aparecer o seu valor será na mesma 37
(0, 1) -, 37 n/a o elemento poderá aparecer uma vez; se ele não aparecer tal não será necessário; se ele aparecer e estiver vazio, o seu valor é 37; senão o seu valor deverá ser aquele que foi dado
n/a opcional, -, 37 o atributo poderá aparecer uma vez; se ele não aparecer, o seu valor é 37, senão o seu valor deverá ser aquele que foi atribuído
(0, 2) -, 37 n/a o elemento pode aparecer uma ou duas vezes, ou até nem aparecer; se o elemento não aparecer, tal não será necessáriamente aplicável; se ele aparecer e estiver vazio, o seu valor será 37;senão o seu valor deverá ser aquele que foi dado; em geral, os valores minOccurs and maxOccurs poderão ser ser números inteiros positivos, e o valor maxOccurs também poderá ser "unbounded"
(0, 0) -, - probido, -, - elemento/atributo não necessitam de aparecer indicados
Note-se que tanto o minOccurs, o maxOccurs, como ainda o use não podem aparecer nas declarações dos elementos e atributos globais.

2.2.2 Elementos e Atributos Globais

Os elementos e os atributos globais são criados pelas declarações que aparecem como filhas (derivadas) do elemento [schema (esquema)]. Uma vez declarados, o elemento ou o atributo global podem ser referenciados numa ou mais declarações, usando para isso o atributo ref, segundo aquilo que foi acima descrito.A declaração que referencia o elemento global possibilita que o elemento apareça no documento de instância, no mesmo contexto que o da referida declaração. Assim, por examplo, o elemento [comment (comentário)] aparece em po.xml ao mesmo nível que os elementos shipTo, billTo e items, uma vez que a declaração que referência comment, aparece na definição do tipo complexo, ao mesmo nível que as declarações dos outros três elementos.

A declaração de um elemento global possibilita ainda que esse elemento apareça no topo do documento de instância. Daí que purchaseOrder, a qual é declarada como elemento global em po.xsd, pode aparecer como elemento de topo em po.xml. Note-se que este princípio básico também permitirá que o elemento comment apareça no princípio de documentos como o po.xml.

Existe porém um número de advertências referentes ao uso dos atributos e dos elementos globais. Uma delas refere-se ao facto das declarações globais não poderem conter referências; as declarações globais devem identificar directamente os tipos simples e os tipos complexos. Para ser mais objectivo, as declarações globais não podem conter o atributo ref, elas tem de servir do atributo type (ou, de acordo com a nossa breve descrição, serem seguidas por uma definição do tipo anónimo). Uma segunda advertência será o facto das restrições cardinais não poderem ser colocadas em declarações globais, embora elas possam ser colocadas em referências locais que referenciem as declarações globais. Por outras palavras, as declarações globais não podem conter os atributos minOccurs, maxOccurs, ou ainda use.

2.2.3 2.2.3 Conflitos relacionados com a atribuição dos nomes

Acabámos de descrever como definir os novos tipos complexos (por exemplo: PurchaseOrderType), como declarar elementos (por exemplo: purchaseOrder) e como declarar atributos (por exemplo: orderDate). Essas actividades envolvem geralmente a atribuição de um novo, de forma que a questão que agora se coloca é a seguinte: O que é que acontece se atribuírmos o mesmo nome a duas coisas distintas? A resposta a esta pergunta dependerá das duas coisas em questão, embora o mais certo seja, que quanto mais similares forem essas duas coisas, maior será a probabilidade de conflito entre elas.

Eis aqui alguns exemplos para ilustrar o caso referente aos problemas causados pela atribuição de nomes iguais a elementos diferentes. Digamos por exemplo, que esses dois elementos ou objectos se tratam de tipos, definindo nós aqui um tipo complexo chamado USStates e um tipo simples chamado USStates: entre eles dar-se-á automáticamente um conflito. Se os dois objectos forem nomeadamente um tipo e um elemento ou atributo, definindo aqui por exemplo um tipo complexo chamado USAddress e um elemento chamado USAddress, não existirá qualquer tipo de conflito entre eles. Se esses dois objectos pertencerem a dois tipos diferentes (isso significa que eles se tratam de elementos não globais) e se nós definirmos um elemento chamado nome, como parte pertencente ao tipo USAddress, e ainda um segundo elemento chamado nome, como parte pertencente ao tipo Item, então não haverá qualquer conflito. (Tais objectos são por vezes denominados de declarações dos elementos locais.) Por fim, se esses dois objectos forem tipos, se você definir um deles como tipo simples decimal e o Esquema XML definir o outro, não haverá qualquer conflito entre eles. A razão para a aparente contradição verificada neste último exemplo, dá-se ao facto dos dois tipos pertencerem a espaços-nominais (namespaces) diferentes. Nós aprofundaremos o uso dos espaços-nominais no esquema, numa secção posterior.

previous sub-section next sub-section2.3 Tipos Simples

O esquema da nota de encomenda especifica vários elementos e atributos que têm tipos simples. Alguns desse tipos simples, como por exemplo string e decimal, são construídos no Esquema XML, ao passo que os outros derivam dessas construções (built-ins). Por exemplo, o atributo partNum possui um tipo denominado de SKU (Stock Keeping Unit), o qual deriva de string. Ambos os tipos simples aí incorporados, bem como as suas derivações, poderão ser usados em todas as declarações de elementos e atributos. No Quadro 2 são listados todos os tipos simples incorporados no Esquema XML, juntamente com exemplos dos diferentes tipos.

Quadro 2. Tipos Simples incorporados no Esquema XML
Tipos Simples Exemplos (delimitados por vírgulas) Notas
string Confirma que isto é eléctrico
normalizedString Confirma que isto é eléctrico ver (3)
token Confirma que isto é eléctrico ver (4)
base64Binary GpM7  
hexBinary 0FB7  
integer ...-1, 0, 1, ... ver (2)
positiveInteger 1, 2, ... ver (2)
negativeInteger ... -2, -1 ver (2)
nonNegativeInteger 0, 1, 2, ... ver (2)
nonPositiveInteger ... -2, -1, 0 ver (2)
long -9223372036854775808, ... -1, 0, 1, ... 9223372036854775807 ver (2)
unsignedLong 0, 1, ... 18446744073709551615 ver (2)
int -2147483648, ... -1, 0, 1, ... 2147483647 ver (2)
unsignedInt 0, 1, ...4294967295 ver (2)
short -32768, ... -1, 0, 1, ... 32767 ver (2)
unsignedShort 0, 1, ... 65535 ver (2)
byte -128, ...-1, 0, 1, ... 127 ver (2)
unsignedByte 0, 1, ... 255 ver (2)
decimal -1.23, 0, 123.4, 1000.00 ver (2)
float -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN equivalente ao “single-precision 32-bit floating point”, NaN significa “not a number” (não é um número), ver (2)
double -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN equivalente ao “double-precision 64-bit floating point”, ver (2)
boolean true (verdadeiro), false (falso), 1, 0
duration P1Y2M3DT10H30M12.3S 1 year (ano), 2 months (meses), 3 days (dias), 10 hours (horas), 30 minutes (minutos), e 12.3 seconds (segundos)
dateTime 1999-05-31T13:20:00.000-05:00 31 de Maio de 1999, 13.20 segundo a hora Eastern Standard Time, a qual anda cinco horas para trás, tendo como base de partida a hora UCT (Universal), ver (2)
date 1999-05-31 ver (2)
time 13:20:00.000, 13:20:00.000-05:00 ver (2)
gYear 1999 1999, ver (2) (5)
gYearMonth 1999-02 mês de Fevereiro, não pormenorizando o número referente aos dias, ver (2) (5)
gMonth --05 Maio, ver (2) (5)
gMonthDay --05-31 cada 31 de Maio, ver (2) (5)
gDay ---31 o dia 31 de Maio, ver (2) (5)
Name shipTo Tipo de nome em XML 1.0
QName po:USAddress Espaço-nominal Qname em XML
NCName USAddress Espaço-nominal NCName em XML, o que significa que é um Qname sem o prefixo nem os dois pontos
anyURI
http://www.example.com/,
http://www.example.com/doc.html#ID5
language en-GB, en-US, fr valores válidos para [xml:lang], como o definido em XML 1.0
ID atributo do tipo XML 1.0 [ID], ver (1)
IDREF atributo do tipo XML 1.0 IDREF, ver (1)
IDREFS atributo do tipo XML 1.0 IDREFS, ver (1)
ENTITY atributo do tipo XML 1.0 ENTITY, ver (1)
ENTITIES atributo do tipo XML 1.0 ENTITIES, ver (1)
NOTATION atributo do tipo XML 1.0 NOTATION, ver (1)
NMTOKEN
US,
Brasil
atributo do tipo NMTOKEN em XML 1.0, ver (1)
NMTOKENS
US UK,
Brasil, Canada, México
atributo do tipo NMTOKENS XML 1.0, o que à letra significa uma lista separada com espaços em branco de NMTOKEN's, ver (1)
Notas: (1) Para manter a compatibilidade entre o Esquema XML e XML 1.0 DTDs, os tipos simples ID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION, NMTOKEN, NMTOKENS deverão ser apenas usados nos atributos. (2) Um valor deste tipo pode ser representado por mais do que um formato lexical. Por exemplo, 100 e 1.OE2 são ambos formatos oscilantes válidos representando "cem". Foram contudo estabelecidas regras para este tipo, as quais definem um formato lexical canónico, ver Esquema XML, Parte 2. (3) Os caractéres referentes à mudança de linha, ao tabulador e à tecla de retorno num atributo do tipo [normalizedString], são transformados em espaços em branco, antes do processamento do esquema.(4) Como no caso do atributo [normalizedString], os espaços em branco adjacentes são limitados a um único espaço em branco, e os espaços em branco no princípio e no fim são removidos. (5) O prefixo "g" assinala os períodos de tempo no calendário Gregoriano.

Os tipos simples novos são definidos através da sua derivação a partir dos tipos simples já existentes (built-in`s e derivadas).Falando de uma forma mais detalhada, nós poderemos derivar um novo tipo simples através da restrição de um tipo simples já existente ou, por outras palavras, a escala dos valores válidos para este novo tipo é constituída por um sub-conjunto da escala dos valores dos tipos já existentes. Nós utilizamos o elemento simpleType para definir e nomear o novo tipo simples. Nós utilizamos o elemento restriction [restrição] para indicar o tipo já existente (básico) e para identificar as "facetas"(do Inglês: "facets") ou propriedades que restringem a escala de valores. A lista completa com essas propriedades é fornecida no documento Appendix B.

Suponhamos que nós queremos criar um novo tipo de inteiros, ao qual chamamos myInteger e cuja escala de valores está compreendida entre 10000 e 99999 (inclusive). Nós baseamos a nossa definição no tipo simples integrado (do Inglês: "built-in") integer, cuja escala de valores também inclui´números inteiros maiores do que 10000 e menores do que 99999. Para definir myInteger [meuInteiro], nós limitámos a escala do tipo base integer, empregando duas propriedades, nomeadamente minInclusive e maxInclusive:

Este exemplo mostra-nos uma combinação especial entre um tipo base e duas propriedades ("facets"), com o intuito de definir myInteger, se bem que depois de se deitar uma vista de olhos à lista dos tipos simples integrados bem como às suas propriedades (Apêndice B) se pudessem idealizar ou sugerir outras combinações possíveis.

O esquema da nota de encomenda contém um outro exemplo, mais elaborado, da definição do tipo simples.Um novo tipo simples, denominado de SKU, é derivado (por restrição) do tipo simples string. Além disso, nós restringimos os valores de SKU, utilizando uma propriedade chamada pattern, em conjunção com a expressão regular "\d{3}-[A-Z]{2}" que se pode ler como "três digitos seguidos de um hífen seguido de dois caractéres ASCII em letras maiúsculas":

Esta linguagem de expressões regulares é descrita mais detalhadamente em Apêndice D.

O Esquema XML define doze propriedades, as quais são listadas em Apêndice B. Entre elas, a propriedade enumeration é de especial utilidade e pode ser utilizada para restringir os valores de quase todos os tipos simples, excepto os do tipo boolean. A propriedade enumeration limita um tipo simples a um conjunto de valores distintos. Por exemplo, nós podemos utilizar a propriedade enumeration, a fim de definir um novo tipo simples denominado USState, derivado do tipo string, cujo valor deverá consistir numa das abreviaturas estaduais standard dos EUA:

USState seria uma boa substituição para o tipo string, correntemente utilizado na declaração do elemento state. Através da referida substituição, os valores legais do elemento state ou seja, os sub-elementos de state, em billTo e shipTo, estariam limitados a algum valor de AK, AL, AR, etc. Note que os valores da enumeração que foram específicados para um determinado tipo deverão ser únicos.

2.3.1 Tipos de Listas

O Esquema XML tem o conceito de um tipo de lista, a adicionar aos assim denominados tipos atómicos, os quais constituem a maioria dos tipos listados no Quadro 2. (Os tipos atómicos, os tipos de lista e os tipos de união, todos eles descritos na próxima secção, são colectivamente denominados de tipos simples.) Segundo a perspectiva apresentada pelo Esquema XML, o valor de um tipo atómico é indivisível.Por exemplo, o valor de NMTOKEN denominado de US é indivisível, no sentido em que nenhuma parte de US, tal como por exemplo o caractére "S", fará sentido por si própria, senão e apenas no seu todo. Contrastando com o aspecto acima referido, os chamados tipos (de) lista são compostos por sequências de tipos atómicos o que significa que, consequentemente, as partes de uma sequência (os chamados "átomos") só por si próprias possuem um significado lógico. Por exemplo, NMTOKENS é um tipo de lista, e um elemento deste tipo seria uma lista de elementos NMTOKEN’s, delimitados por espaços em branco, tais como "US UK FR". O Esquema XML tem três tipos de lista integrados (built-ins), respectivamente NMTOKENS, IDREFS e ENTITIES.

Além de utilizar esses tipos de lista integrados, você poderá criar novos tipos de lista, derivando os tipos atómicos existentes. (Você não poderá criar tipos de lista a partir de tipos de lista já existentes, apenas a partir dos tipos complexos.) Por exemplo, para criar uma lista de elementos myInteger’s:

Um dos elementos contidos num documento de instância cujo conteúdo está em conformidade com listOfMyIntType é:

Exemplo
<listOfMyInt>20003 15037 95977 95945</listOfMyInt>

Poder-se-ão aplicar várias propriedades aos chamados tipos de lista: length, minLength, maxLength, pattern, e enumeration. Por exemplo, para definirmos uma lista com nada mais nada menos do que seis Estados americanos (SixUSStates), teremos primeiramente de definir um novo tipo de lista chamada USStateList, a partir de USState e derivar então SixUSStates, restringindo USStateList a apenas seis elementos:

Os elementos cujo tipo seja SixUSStates têm de conter seis itens, devendo ainda cada um desses itens ser um dos valores (atómicos) pertencentes ao tipo USState, como por exemplo:

Exemplo
<sixStates>PA NY CA NY LA AK</sixStates>

Note que é possível derivar um tipo de lista a partir do tipo atómico string. Uma string poderá contudo conter espaços em branco, os quais delimitam os itens num tipo de lista, pelo que você deverá tomar cuidado sempre que usar os tipos de lista cujo tipo base seja string. Suponhamos por exemplo que nós definimos um tipo de lista com uma propriedade do tipo length igual a 3, e um tipo base string. Neste caso a lista com os 3 itens que se segue é válida ou legal:

Exemplo
Asia Europa Africa

A próxima lista que segue, contendo ela também 3 "itens" é ilegal:

Exemplo
Asia Europa América Latina

Ainda que o item "América Latina" possa existir fora da referida lista, na qualidade de string, se ele for incluído nela, o espaço em branco entre América e Latina criará efectivamente um quarto item, não estando portanto este último exemplo em conformidade com o tipo de lista com "3 itens".

previous sub-section next sub-section2.4 Definições de Tipo Anónimo

Os esquemas podem ser construídos através da definição de conjuntos de tipos de nomes, tais como PurchaseOrderType e declarando posteriormente elementos do tipo purchaseOrder que referenciam os tipos usando a construção type=. Este tipo de construção do esquema é directo, mas pode-se tornar lento e indesejável, especialmente se você definir vários tipos que sejam apenas referenciados uma vez e contenham muitas poucas restrições. Em tais casos, um tipo poderá ser mais sucintamente referido, na qualidade de tipo anónimo, o que evitará o trabalho de se ter de nomeá-lo e de referênciá-lo.

A definição do tipo Items em po.xsd contém duas declarações de elementos, as quais se servem de tipos anónimos (item e quantity). Em geral, você poderá identificar os tipos anónimos pela ausência de um type= numa declaração de elementos (ou atributos) e pela presença de uma definição de tipo não-nomeado (sem nome) simpes ou complexo:

Considerando agora o caso do elemento item, ele possui um tipo complexo anónimo, o qual consiste nos elementos productName, quantity, USPrice, comment e shipDate, bem como num atributo denominado de partNum. No caso do elemento quantity, ele possui um tipo simples anónimo derivado do elemento positiveInteger, cujos valores oscilam entre 1 e 99.

previous sub-section next sub-section2.5 Conteúdo dos Elementos

        2.5.1 Tipos Complexos a partir de Tipos Simples
        2.5.2 Conteúdo Misto
        2.5.3 Conteúdo Vazio
        2.5.4 anyType [(qualquerTipo)]

O esquema da nota de encomenda contém vários exemplos de elementos que contém por sua vez outros elementos (exemplo: itens), de elementos possuindo atributos e contendo outros elementos (e.g. shipTo) ou de elementos contendo apenas um valor do tipo simples (exemplo: USPrice). Nós não tivemos contudo ainda a oportunidade de observar elementos que possuíssem atributos, mas contendo apenas um valor do tipo simples, bem como também ainda não vimos elementos que contenham outros elementos misturados com o conteúdo dos caractéres, ou ainda um elemento que não possua nenhum conteúdo na sua totalidade.Nesta secção, nós iremos examinar essas variações dos modelos de conteúdos dos elementos.

2.5.1 Tipos Complexos a derivados partir de Tipos Simples

Consideremos primeiramente a forma como declarar um elemento que contenha um atributo e que seja do tipo simples. Num documento de instância, tal documento poderá aparecer sob a forma de:

Exemplo
<internationalPrice currency="EUR">423.46</internationalPrice>

O esquema da nota de encomenda especifica o elemento USPrice, o qual é ainda um ponto básico ou de partida:

Exemplo
<xsd:element name="USPrice" type="decimal"/>

Agora, como é que nós somamos um atributo a este elemento? Como nós tivemos a oportunidade de referir anteriormente, os tipos simples não podem conter atributos e o elemento decimal é do tipo simples. Por isso, nós temos de definir um tipo complexo que transporte a declaração do atributo. Nós pretendemos ainda que o conteúdo seja do tipo simples decimal. Assim, a nossa questão de partida assume uma outra forma: Como definir um tipo complexo a partir de um tipo simples decimal? A solução é derivar um novo tipo complexo a partir de um tipo simples decimal:

Nós usamos o elemento complexType para iniciar a definição de um novo tipo (anónimo). Para indicar que o modelo do conteúdo deste novo tipo contém dados constituídos apenas por caractéres e por mais nenhum elemento nós utilizamos um elemento do tipo simpleContent. Finalmente, nós derivamos o novo tipo de elemento através da extensão do tipo simples decimal. Esta extensão consiste na soma de um atributo currency, usando a declaração de um atributo standard.(Nós cobrimos o tema [derivação dos tipos] mais detalhadamente em Conceitos Avançados II: A Nota de Encomenda Internacional (§4).) O elemento internationalPrice que é desta forma declarado, aparecerá numa instância, como foi exemplificado no início desta secção.

2.5.2 Conteúdos Mistos

A construção do esquema da ordem de encomenda pode ser caracterizada e definida como elementos contendo sub-elementos, e os sub-elementos dos níveis mais profundos contêm apenas dados formados por caractéres. O Esquema XML também possibilita a construção de esquemas, nos quais os dados constituídos por caractéres não possam aparecer lado a lado com os sub-elementos ou ainda que esses mesmos dados não se restrinjam aos sub-elementos dos níveis mais profundos.

Para ilustrar este aspecto, consideremos o fragmento seguinte, extraído da carta de um cliente que utiliza alguns dos mesmos elementos contidos na nota de encomenda:

Note-se que o texto aparece entre os elementos e os elementos derivados. Mais específicamente, o texto aparece entre os elementos salutation, quantity, productName e shipDate, os quais são nomeadamente as derivadas do elemento letterBody, e ainda ao redor do elemento name, o qual é a derivada da derivada do elemento letterBody. O fragmento do esquema que se segue declara ou especifica o elemento letterBody:

Os elementos que aparecem na carta do cliente são declarados e os seus tipos são definidos usando as construções do tipo element e complexType, as quais tivémos anteriormente a oportunidade de ver. Para possibilitar que os dados formados por caractéres possam aparecer entre os elementos derivados do elemento letterBody, o atributo mixed, contido na definição do tipo, é definido como [true (verdadeiro)].

Note que o modelo mixed contido no Esquema XML difere fundamentalmente do Modelo Misto XML 1.0. No modelo misto do Esquema XML, a ordem e o número dos elementos derivados que aparecem numa instância devem estar em concordância com a ordem e número dos elementos derivados que são especificados no modelo. Contrastando com o caso anterior, no modelo misto do Esquema XML 1.0, a ordem e o número de elementos derivados que aparecem na instância não poderão ser restringidos ou limitados. Sumáriamente, o Esquema XML fornece uma validação integral dos modelos mistos, contrastando pois com a validação parcial do esquema que nos é fornecido em XML 1.0.

2.5.3 Conteúdo Vazio

Suponhamos agora que pretendemos que o elemento internationalPrice contenha simultâneamente a unidade monetária e o preço na qualidade dos valores dos atributos, em vez de termos dois valores separados, ou seja, atributo e conteúdo. Por exemplo:

Exemplo
<internationalPrice currency="EUR" value="423.46"/>

Este elemento não possui qualquer tipo de conteúdo; o modelo do seu conteúdo está vazio. Para definir um tipo cujo conteúdo esteja vazio, nós defenimos essencialmente um tipo que permita apenas elementos no seu conteúdo, mas não declaramos factualmente qualquer um desses elementos, de forma que o modelo do seu conteúdo estará vazio:

Neste exemplo, nós definimos um tipo (anónimo) contendo um conteúdo do tipo complexContent, ou seja, apenas elementos only. O elemento complexContent sinaliza o facto de nós pretendermos limitar ou alargar o modelo do conteúdo de um tipo complexo, e a restrição do elemento anyType declara dois atributos mas não apresenta qualquer conteúdo para o elemento (ver Derivando Tipos Complexos por Restrição (§4.4) para informações mais detalhadas acerca dos limites ou restrições). O elemento internationalPrice que é desta forma declarado, poderá aparecer legítimamente numa instância, como foi exemplificado no exemplo acima dado.

A sintaxe precedente a um elemento com um conteúdo vazio é relativamente detalhada e é possível declarar o elemento internationalPrice de uma maneira mais compacta:

Esta síntaxe compactada funciona dado que um tipo complexo que seja definido sem qualquer tipo de conteúdo do tipo simpleContent ou complexContent é interpretado como uma abreviatura do conteúdo complexo que restringe o elemento anyType.

2.5.4 anyType [(qualquerTipo)]

O elemento anyType representa uma abstração denominada de ur-type o qual é o tipo básico a partir do qual todos os tipos simples e complexos são derivados. Um elemento do tipo anyType não restringe o seu conteúdo de nenhuma forma. É possível utilizar anyType da mesma maneira que se utilizam os outros tipos, como por exemplo:

Exemplo
<xsd:element name="anything" type="xsd:anyType"/>

O conteúdo do elemento que foi desta forma declarado não está restringido, de forma que o valor do elemento poderá ser 423.46, mas poderá ser de igual forma uma outra outra sequência de caractéres, ou até mesmo uma mistura de caractéres e de elementos. De facto, o elemento anyType é o tipo considerado por default, aquando não se tiver especificado nenhum outro tipo, o que poderia ser escrito da seguinte forma:

Exemplo
<xsd:element name="anything"/>

Se se necessitar que o conteúdo do elemento esteja ausente de quaisquer restrições, como por exemplo no caso de elementos que contenham uma prosa, a qual requira o encaixe de uma marca (markup), a fim de estar apta ao suporte internacional então, a declaração efectuada por defeito ou uma sua derivada que seja ligeiramente restringida poderão ser as mais adequadas. O tipo text, descrito em Any Element (Qualquer Elemento), Any Attribute (Qualquer Atributo) (§5.5), é um dos exemplos referentes a esse tipo, o qual é apropriado para tais fins.

previous sub-section next sub-section2.6 Anotações

O Esquema XML fornece-nos 3 elementos destinados à anotação dos esquemas, de forma a beneficiar tanto as leituras como as aplicações humanas. Nós colocamos a descrição de um esquema básico e a informação referente aos direitos de autor numa nota de encomenda dentro do elemento documentation, a qual será a localização mais recomendada para todo o tipo de material destinada à leitura humana. Nós recomendamos-lhe que use o atributo xml:lang em quaisquer dos elementos de documentação, com o fim de indicar a linguagem da informação. Alternativamente, você poderá indicar a linguagem de toda a informação contida num esquema através da colocação do atributo xml:lang no elemento schema.

O elemento appinfo, o qual não utilizámos no esquema da nota de encomenda, pode ser utilizado para fornecer informações respeitantes a ferramentas, folhas de estilo (stylesheets) e outras aplicações. Um exemplo interessante, onde se utiliza o elemento appinfo é o do esquema , o qual descreve os tipos simples contidos no Esquema XML Part 2: Tipos de dados. A informação que descreve este esquema, cujas propriedades são aplicáveis a tipos simples em particular, é representada no interior dos elementos appinfo, e utilizada na aplicação com o fim de gerar automáticamente o texto destinado ao documento do Esquema XML, Parte 2.

Tanto documentation como appinfo, aparecem na qualidade de sub-elementos do elemento annotation, o qual poderá aparecer ele próprio no princípio da maioria das construções dos esquemas. Para ilustrar este caso, o exemplo seguinte mostra-nos os elementos do tipo annotation aparecendo no princípio de uma declaração de elementos e de uma definição do tipo complexo:

O elemento annotation também pode aparecer no início de outras construções de esquemas, tais como as indicadas pelos elementos schema, simpleType e attribute.

previous sub-section next sub-section2.7 Construindo Modelos de Conteúdo

As definições de tipos complexos contidos no esquema da nota de encomenda declaram as sequências de elementos que terão de aparecer no documento de instância. A ocorrência de elementos individuais, declarados nos assim chamados modelos de conteúdo desses tipos pode ser opcional, assim como o valor 0 indicado para o atributo minOccurs (por exemplo em comment), ou ser restringida de uma outra forma aos valores de minOccurs e maxOccurs. O Esquema XML também fornece restrições que se aplicam aos grupos de elementos que aparecem no modelo do conteúdo. Essas restrições reflectem as restrições que estão disponíveis em XML 1.0 bem como outras adicionais.Note que as restrições não se aplicam aos atributos.

O Esquema XML possibilita que grupos de eleemntos sejam definidos e nomeados, de forma a que esses elementos possam ser usados para construir os modelos de conteúdo de tipos complexos ( mimetizando o uso comum das entidades dos parâmetros contidos em XML 1.0). Também se poderão definir grupos não nomeados de elementos e, conjuntamente com os elementos contidos em grupos nomeados, ser restringidos de forma a aparecerem na mesma ordem (sequência) pela qual eles são declarados. Alternativamente, eles poderão ser restringidos de forma a que apenas um dos elementos possa aparecer numa instância.

Para ilustrar este caso, nós introduzimos dois grupos na definição do esquema da nota de encomenda PurchaseOrderType, de forma a que elas possam conter apenas um endereço de envio e de facturamento em separado ou apenas endereço para os casos em que tanto o envio como o facturamento sejam co-localizados:

O elemento choice [escolha], contido no grupo, permite que apenas uma dos seus filhos (derivadas) apareça na na instância. Considera-se aqui como filho, um elemento contido em group que referencie o chamado grupo shipAndBill, o qual consiste na sequência de elementos shipTo, billTo, sendo o seu segundo filho ou derivada o elemento singleUSAddress. Por isso, num documento de instância, o elemento purchaseOrder deverá conter um elemento shipTo, seguido de um elemento billTo ou um elemento singleUSAddress. O grupo choice é seguido pelas declarações dos elementos comment e items , sendo tanto o grupo choice como as declarações dos elementos as filhas ou as derivadas do grupo sequence. A consequência ou efeito destes vários grupos consiste no facto dos elementos do endereço terem de ser seguidos pelos elementos comment e items segundo essa mesma ordem.

Existe uma terceira opção destinada à restrição de elementos num grupo: Todos os elementos contidos num grupo poderão aparecer uma ou nenhuma vez e em qualquer ordem. O grupo all (o qual fornece uma versão simplificada de SGML & Connector) é limitado ao nível do topo de qualquer modelo de conteúdo. Além disso, as derivadas desse grupo deverão ser constituídas por elementos individuais (e não grupos!), não podendo nenhum desses elementos contidos no modelo do conteúdo aparecer mais do que uma vez, o que significa que os valores permisssíveis de minOccurs e maxOccurs são nomeadamente 0 e 1. Para permitir por exemplo que os elementos derivados de purchaseOrder apareçam numa ordem qualquer, nós poderíamos redefinir PurchaseOrderType da seguinte maneira:

Segundo esta definição, um elemento do tipo comment poderá opcionalmente aparecer contido em purchaseOrder, podendo ele aparecer antes ou depois dos elementos shipTo, billTo e items, mas contudo apenas uma vez. Além disso, as estipulações estabelecidas num grupo do tipo all não nos permitem declarar um elemento do tipo comment fora desse grupo, de forma a possibilitar que ele possa aparecer mais do que uma vez. O Esquema XML estipula que um grupo all tenha de aparecer na qualidade de filho único (derivada), no topo de um modelo de conteúdo. Por outras palavras, a seguinte procedura não nos é permitida:

Finalmente, os grupos com um nome e os grupos anónimos que aparecem nos modelos de conteúdo (representados respectivamente por group, choice, sequence e all) podem transportar atributos do tipo minOccurs e maxOccurs. Através da combinação dos vários grupos fornecidos pelo Esquema XML e através da definição dos valores para minOccurs e maxOccurs, é-nos possível representar qualquer modelo de conteúdo que possa ser expresso por intermédio de um XML 1.0 DTD. Além disso, o grupo all fornece ainda um poder ou uma capacidade de expressão adicional.

previous sub-section next sub-section2.8 Grupos de Atributos

Suponhamos que nós pretendemos fornecer informações adicionais acerca de cada um dos itens contidos na nota de encomenda, como por exemplo o peso de cada um dos itens ou produtos vendidos, bem como o método de pagamento preferido. Nós poderemos realizar essa tarefa adicionando as declarações dos atributos weightKg e shipBy à definição do tipo dos elementos contidos em item (anónimo):

Alternativamente, nós poderemos criar um grupo de atributos nomeado (ao qual foi, por assim dizer, atribuído um nome) contendo todos os desejados atributos do elemento item, e referenciar esse mesmo grupo através do seu nome na declaração do elemento item:

Usando-se um grupo de atributos desta forma poder-se-á melhorar a legibilidade dos esquemas e facilitar a actualização dos esquemas, uma vez que um grupo de atributos poderá ser definido e editado apenas num determinado local e referenciado em múltiplas definições e declarações. Essas características dos grupos de atributos torna-as distintas para as entidades dos parâmetros contidos em XML 1.0. Note no entanto que um grupo de atributos poderá conter outros grupos de atributos. É ainda de salientar que tanto as declarações de atributos como as referências aos grupos de atributos devem aparecer posicionadas no fim das definições do tipo complexo.

previous sub-section 2.9 Valores Nulos

Um dos itens pertencentes à nota de encomenda e listado em po.xml, o Lawnmower, não contém nenhum elemento shipDate. Dentro deste mesmo contexto, o autor do esquema poderá ter pretendido com tal ausência avisar que o item ainda não será enviado. Mas em geral, a ausência de um elemento não possui qualquer significado em particular: Ela poder-nos-á indicar que a informação é desconhecida ou não aplicável, ou que o elemento poderá estar ausente por outras razões não especificadas. Por vezes é preferível representar um item que não tenha sido ainda despachado, informação desconhecida ou informação que não seja aplicável explicitamente através de um elemento, do que através da sua ausência.Poder-nos-á ser por exemplo mais desejável representar um valor "nulo" a ser enviado para ou da respectiva base de dados com um eleemnto que esteja presente. Tais casos poderão ser representados através da utilização do mecanismo dos valores nulos do Esquema XML, o qual permite que o elemento apareça com ou sem o referido valor nulo.

O mecanismo dos valores nulos do Esquema XML envolve um sinal nulo que esteja "fora da frequência" ["out of band"]. Por outras palavras, não existe nenhum valor nulo actual que apareça sob a forma de conteúdo do elemento, havendo em vez disso um atributo para indicar que o conteúdo do elemento é nulo. Para ilustrar este caso, nós modificaremos aqui a declaração do elemento shipDate, de forma a que os valores nulos possam ser sinalizados:

Exemplo
<xsd:element name="shipDate" type="xsd:date" nillable="true"/>

E para representar explícitamente o facto do elemento shipDate conter um valor nulo no documento de instância nós definimos o atributo nil (do espaço-nominal ou namespace do Esquema XML para as instâncias) como sendo verdadeiro [true]:

Exemplo
<shipDate xsi:nil="true"></shipDate>

O atributo nil é definido como sendo parte do espaço-nominal do Esquema XML destinado às instâncias, http://www.w3.org/2001/XMLSchema-instance, e deverá portanto aparecer no documento de instância com um prefixo (como por exemplo xsi:) associado a esse espaço-nominal. (Tal como no caso do prefixo xsd:, o prefixo xsi: é usado apenas por convenção.) Note que o mecanismo do valor nulo se aplica apenas os valores do elemento e não aos valores dos atributos. Um elemento que contenha xsi:nil="true" não poderá conter nenhum conteúdo de elementos, mas poderá ainda conter ou transportar atributos.

3 Conceitos Avançados I: Espaços-nominais, Esquemas e Qualificações

Um esquema poderá ser visto como uma colecção (vocabulário) de definições de tipos e declarações de elementos, cujos nomes façam parte dum espaço-nominal em particular, designado por [target namespace] ou espaço-nominal de destino. Os espaços-nominais de destino permitem-nos fazer a distinção entre definições e declarações, do ponto de vista referente ao seu diferente vocabulário. Por exemplo, os espaços-nominais de destino permitir-nos-iam fazer uma distinção entre a declaração do element, contido no vocabulário da linguagem do Esquema XML, e a declaração do element de um hipotético vocabulário pertencente à linguagem química.O primeiro faz parte do espaço-nominal de destino http://www.w3.org/2001/XMLSchema, e o último faz parte de um outro espaço-nominal de destino.

Quando nós quisermos verificar se um determinado documento de instância está ou não em conformidade com um ou mais esquemas (através de um processo chamado validação), nós teremos de identificar quais as declarações dos atributos e definições do tipo de elementos contidas nos esquemas que deverão ser usadas para se determinar quais os elementos e atributos contidos no documento de instância. O espaço-nominal de destino desempenha um papel bastante importante no processo de identificação. Nós examinaremos o papel dos referidos espaços-nominais na próxima secção.

O autor do esquema possui ainda várias opções, as quais afectam a forma como as identidades dos elementos e dos atributos são representadas nos documentos de instância. Mais específicamente, o autor poderá decidir se a aparição dos elementos a atributos localmente declarados num documento de instância deve ou não ser qualificada por um espaço-nominal, usando um prefixo explícito ou implícitamente por defeito. A escolha feita pelo autor do esquema, no que toca à qualificação dos elementos e dos atributos locais, tem um número de implicações respeitantes às estruturas dos esquemas e aos documentos de instância, algumas das quais serão por nós examinadas nas próximas secções.

next sub-section3.1 Espaços-nominais de destino & Locais não qualificados

Numa nova versão do esquema da nota de encomenda, po1.xsd, nós declaramos explícitamente um espaço-nominals e especificamos que ambos os elementos e atributos localmente definidos devem ser não qualificados. O espaço-nominal de destino em po1.xsd é nomeadamente http://www.example.com/PO1, como o indicado pelo valor do atributo targetNamespace.

A qualificação de elementos e atributos locais poderá ser globalmente especificada por de um par de atributos, elementFormDefault e attributeFormDefault, no elemento schema element, ou ser separadamente especificado para cada uma das declarações usando o atributo form. Todos esses valores dos atributos poderão ser definidos como unqualified [não-qualificado] ou qualificado, para indicar os casos em que os elementos e atributos locais declarados deverão ser qualificados ou não.

Em po1.xsd, nós especificámos globalmente a qualificação dos elementos e dos atributos locais, tendo marcado os valores de ambos, elementFormDefault e attributeFormDefault na qualidade de não-qualificados. Falando de uma forma mais objectiva, tais ajustes não serão necessários, porque eles são os valores por defeito estipulados para os dois elementos; Nós fazêmo-lo aqui apenas para realçar o contraste entre este e um outro caso que iremos mais tarde descrever.

Para vermos como se preenche o espaço-nominal de destino deste esquema, nós examinaremos um pouco em torno de cada uma das definições do tipo e declarações de elementos. Começando a partir do fim do esquema, nós definimos primeiramente um tipo de atributo chamado USAddress, o qual é constituído pelos elementos name, street, etc. Uma das consequências deste tipo de definição assenta no facto do tipo USAddress estar incluído no espaço-nominal de destino deste esquema. Em seguida, definiremos um tipo chamado PurchaseOrderType, o qual é constituído pelos elementos shipTo, billTo, comment, etc. O elemento PurchaseOrderType também está incluído no espaço-nominal de destino deste esquema. Repare que as referências dos tipos contidas nas três declarações dos elementos são prefixadas, nomeadamente po:USAddress, po:USAddress e po:comment, e que o prefixo está associado ao espaço-nominal http://www.example.com/PO1. Este espaço-nominal é igual ao espaço-nominal de destino, de forma que o processador deste esquema saberá fazer a distinção entre o esquema da definição do tipo USAddress e a declaração do elemento comment. Também é possível fazer a referência a tipos contidos num outro esquema, o qual contenha um espaço-nominal de destino diferente, possibilitando assim a reutilização das declarações e das definições entre os esquemas.

No princípio do esquema po1.xsd, nós declarámos os elementos purchaseOrder e comment. Eles estão incluídos nos espaços-nominais de destino dos referidos esquemas. O tipo de elemento purchaseOrder contém um prefixo, pela mesma razão que USAddress também contém um prefixo. Contrastando com este facto, o tipo do elemento comment, string, não é prefixado. O esquema po1.xsd contém uma declaração de um espaço-nominal atribuída por defeito, de forma que os tipos que não contenham prefixos, tais como string e eleemntos não prefixados, tais como element e complexType estão associados ao espaço-nominal por defeito http://www.w3.org/2001/XMLSchema. Este é de facto o espaço-nominal de destino do próprio Esquema XML, de forma que o processador do po1.xsd reconhecerá o esquema do Esquema XML -- também conhecido como "esquema para os esquemas" –- para a definição do tipo string e a declaração do elemento chamado element.

Examinemos agora a forma como os espaços-nominais contidos no esquema afectam um documento de instância em conformidade:

O documento de instância declara um espaço-nominal, http://www.example.com/PO1 e associa-o ao prefixo apo:. Este prefixo é usado para qualificar dois elementos contidos no documento, nomeadamente purchaseOrder e comment. Este espaço-nominal é igual ao espaço-nominal de destino do esquema em po1.xsd, de forma que o processador do documento de instância reconhecerá esse esquema no caso das declarações dos elementos purchaseOrder e comment. De facto, os espaços-nominais são assim nomeados, no sentido em que existe um espaço-nominal para os elementos purchaseOrder e comment. Os espaços-nominais de destino contidos no esquema controlam por isso a validação dos espaços-nominais correspondentes na instância.

O prefixo apo: é aplicado aos elementos globais purchaseOrder e comment. Além disso, a presença de elementFormDefault e attributeFormDefault requer que o prefixo não seja aplicado a nenhum dos elementos locais declarados, tais como shipTo, billTo, name e street, não sendo também aplicado a nenhum dos atributos (os quais foram na sua totalidade localmente declarados). Os elementos purchaseOrder [nota de encomenda] e comment [comentário] são elementos globais, dado que eles são declarados dentro do contexto esquema como um todo e não sob a forma de um tipo específico ou particular. Por exemplo, a declaração de purchaseOrder aparece na qualidade de derivada do elemento schema em po1.xsd, ao passo que a declaração do elemento shipTo aparece como derivada do elemento complexType, o qual define PurchaseOrderType.

Sempre que não seja necesário que os elementos e os atributos locais sejam qualicados, o autor do documento de instância requer algum conhecimento acerca dos detalhes do esquema, de forma a poder criar documentos de instância com um esquema válido. Mais específicamente, se o autor puder estar certo que apenas o elemento da raíz (tal como por exemplo purchaseOrder) é global, ele terá então de qualificar apenas esse elemento da raíz. Como alternativa, o autor poderá ter o conhecimento de que todos os elementos foram globalmente declarados, de forma que todos os elementos contidos no documento de instância poderão ser prefixados, tirando assim talvez alguma vantagem da declaração dos espaços-nmominais atribuídos por defeito.(Nós examinamos esta aproximação mais detalhadamente no Tema Declarações Globais vs. Declarações Locais.) Por outro lado, se não existir nenhum padrão uniforme relativo às declarações globais e locais, o autor necessitará de conhecimentos detalhados acerca do esquema, de forma a poder aplicar correctamente um prefixo aos elementos e atributos globais.

previous sub-section next sub-section3.2 Locais Qualificados

Poderá ser necessário que os elementos e atributos tenham de ser individualmente qualificados, embora comecemos aqui por descrever a forma como se qualificam os elementos locais. Para especificar que todos os elementos localmente declarados num esquema devem estar qualificados, nós definimos o valor do elemento elementFormDefault como qualificado:

Exemplo
Modificações efectuadas em po1.xsd para o ajustamento dos Locais Qualificados
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.example.com/PO1"
        targetNamespace="http://www.example.com/PO1"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified">

  <element name="purchaseOrder" type="po:PurchaseOrderType"/>
  <element name="comment"       type="string"/>

  <complexType name="PurchaseOrderType">
    <!-- etc. -->
  </complexType>

  <!-- etc. -->

</schema>

Neste documento de instância em conformidade, nós qualificamos todos os elementos explícitamente através de:

Alternativamente, nós poderemos substituir a qualificação explícita de vários elementos por uma qualificação implícita fornecida por um espaço-nominal atribuído por defeito, como é exibido em po2.xml:

Em po2.xml, todos os elementos contidos na instância pertencem ao mesmo espaço-nominal e a declaração deste mesmo declara um espaço-nominal atribuído por defeito a ser aplicado a todos os elementos contidos no documento de instância. Por isso, será desnecessário prefixar qualquer um desses elementos explícitamente. Apresentamos como ilustração do uso de elementos qualificados, nos esquemas contidos em Conceitos Avançados III: O Relatório Trimestral (§5) todos os elementos qualificados que são requeridos.

A qualificação dos atributos é bastante similar à a qualificação dos elementos. Os atributos que tenham de ser qualificados, quer pelo facto de terem sido globalmente declarados ou dado que o atributo attributeFormDefault é definido como qualificado, aparecem prefixados nos documentos de instância. Um exemplo prático de atributos qualificados é o do atributo xsi:nil, o qual foi introduzido em Valores Nulos (§2.9). De facto, os atributos que tenham de ser qualificados deverão ser explicitamente prefixados, dado que a especificação dos Espaços-nominais contidos em XML não nos fornece um mecanismo que possibilite a atribuição de valores por defeito aos espaços-nominais dos atributos. Os atributos aos quais não lhes seja requerida uma qualificação, aparecem nos documentos de instância ausentes de prefixo, o que é o caso mais típico.

O mecanismo de qualificação que nós tivemos a oportunidade de descrever até aqui, controlou todas as declarações dos elementos locais e atributos contidos num determinado espaço-nominal de destino.Também nos será possível controlar as qualificações numa declaração constituída por declarações básicas usando o atributo form. Por exemplo, para se requerir que o atributo localmente declarado publicKey também seja qualificado nas instâncias, nós teremos de atender ao seguinte procedimento:

Note-se que o valor do atributo form anulará o valor do atributo attributeFormDefault em pró do atributo publicKey. O atributo form pode ser aplicado numa declaração de elementos desse mesmo modo. Eis aqui o exemplo de um documento de instância em conformidade com este tipo esquema:

previous sub-section next sub-section3.3 Declarações Globais vs. Declarações Locais

Um outro estilo, a aplicar sempre que todos os elementos nominais forem únicos no interior de um espaço-nominal, será a criação de esquemas nos quais todos os elementos sejam globais. Isto é de facto similar ao uso de numa DTD. No exemplo mais abaixo, nós modificámos o original po1.xsd, de forma a que todos os elementos fossem globalmente declarados. Note-se no entanto aqui que nós omitimos os atributos elementFormDefault e attributeFormDefault, de forma a enfatizar o facto dos seus valores serem irrelevantes, sempre que existam aí apenas declarações de elementos e atributos globais.

Exemplo
Versão modificada de po1.xsd, na qual se utilizaram apenas as declarações de elementos globais
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.example.com/PO1"
        targetNamespace="http://www.example.com/PO1">

  <element name="purchaseOrder" type="po:PurchaseOrderType"/>

  <element name="shipTo"  type="po:USAddress"/>
  <element name="billTo"  type="po:USAddress"/>
  <element name="comment" type="string"/>

  <element name="name" type="string"/>
  <element name="street" type="string"/>

  <complexType name="PurchaseOrderType">
    <sequence>
      <element ref="po:shipTo"/>
      <element ref="po:billTo"/>
      <element ref="po:comment" minOccurs="0"/>
      <!-- etc. -->
    </sequence>
  </complexType>

  <complexType name="USAddress">
    <sequence>
      <element ref="po:name"/>
      <element ref="po:street"/>
      <!-- etc. -->
    </sequence>
  </complexType>

  <!-- etc. -->

</schema>

Esta versão global de po1.xsd valida o documento de instância po2.xml, o qual e como já tivemos a oportunidade de descrever, também é um esquema válido face à versão "qualificada" de po1.xsd. Por outras palavras, ambas as aproximações dos esquemas poderão validar o mesmo documento, o qual contém um espaço-nominal atribuído por defeito. Assim e por um lado, essas duas aproximações são similares, embora por outro lado elas difiram bastante entre si. Falando de uma forma mais específica, quando todos os elementos são globalmente declarados, não é possível tirar proveito dos nomes locais. Por exemplo, você poderá apenas declarar um elemento global intitulado "title" [título]. Você poderá contudo declarar ainda localmente o elemento "title", o qual contém um tipo string e é um sub-elemento de "book". Ainda dentro do mesmo esquema (espaço-nominal de destino), você poderá declarar um segundo elemento, tamém ele intitulado de "title", o qual consiste na enumeração dos valores "Mr Mrs Ms" (Sr. Srs. Sra.).

previous sub-section 3.4 Espaços-nominais de Destino não Declarados

No Capítulo Conceitos Básicos: A Nota de Encomenda (§2), nós explicámos os princípios básicos do Esquema XML utilizando um esquema, no qual não se declarou nenhum espaço-nominal de destino e ainda um documento de instância no qual não se declarou nenhum espaço-nominal.Daí que se coloque a questão: Qual é respectivamente o espaço-nominal destes exemplos e como é que ele é referenciado?

No esquema pertencente à nota de encomenda, po.xsd, nós não declarámos nenhum espaço-nominal de destino para o esquema, ou tão-pouco declarámos um prefixo (como por exemplo po: ), associado ao espaço-nominal de destino do esquema, através do qual nós nos poderíamos referir aos tipos e aos elementos declarados e definidos no interior do mesmo. A consequência da não declaração dos espaços-nominais de destino num esquema assenta no facto das definições e declarações desse mesmo esquema, tais como por exemplo USAddress e purchaseOrder, serem referenciados sem qualquer qualificação dos espaços-nominais. Por outras palavras, não existe nenhum prefixo explícito do espaço-nominal aplicado às referências nem nenhum espaço-nominal implícito por defeito aplicado à referência. Assim por exemplo, o elemento purchaseOrder é declarado, usando-se a referência do tipo PurchaseOrderType. Contrastando com o acima referido, todos os elementos e tipos do Esquema XML usados po.xsd são explícitamente qualificados através do prefixo xsd:, o qual é associado ao espaço-nominal do Esquema XML.

Em casos onde o esquema seja designado sem a ajuda de um espaço-nominal de destino, é-se extremamente recomendado que todos os elementos e tipos contidos no Esquema XML sejam explicitamente qualificados sem a ajuda de um prefixo, como por exemplo xsd:, o qual é associado ao espaço-nominal do Esquema XML (como em po.xsd). O mais provável nesta recomendação será que caso os elementos e os tipos contidos no Esquema XML sejam associados ao respectivo espaço-nominal por defeito ou seja, sem prefixos, então nesse caso, as referências feitas aos tipos de Esquema XML poderão não ser diferenciadas das referências feitas aos tipos [utilizador definido].

As declarações de elementos dos esquemas que não possuam um espaço-nominal de destino, validam assim elementos não qualificados, no documento de instância.Isso significa respectivamente que elas validam elementos para os quais não foi atribuída nenhuma qualificação do espaço-nominal, quer através de um prefixo explícito ou por defeito (xmlns:). Assim, para validar um documentos tradicional em XML 1.0, o qual não utilise qualquer tipo de espaços-nominais, você terá de criar um esquema sem espaços-nominais de destino. É claro que existem muitos documentos em XML 1.0 que não se servem de espaços-nominais, de forma que lógicamente também existirão muitos documentos de esquemas escritos sem qualquer espaço-nominal de destino; você terá de se certificar de que inseriu no seu processador o documento constituído por um esquema que corresponda ao vocabulário que você pretende validar.

4 Conceitos Avançados II: A Nota de Encomenda Internacional

O esquema da nota de encomenda descrito no Capítulo Conceitos Básicos: A Nota de Encomenda (§2) estava contido num único documentos, e a maioria das construções desse esquema – tais como as declarações dos elementos e as definições dos tipos – eram construídas a partir da base. Na realidade, os autores quererão certamente compôr os esquemas a partir das construções localizadas em documentos múltiplos bem como criar novos tipos baseados noutros tipos já existentes. Nesta secção, nós examinaremos os mecanismos que permitem materializar tais composições ou criações.

next sub-section4.1 O Esquema em Documentos Variados

À medida que os esquemas se vão tornando maiores, torna-se necessário ou desejável a divisão do seu conteúdo ao longo de vários documentos de esquemas, de forma a proporcionar assim uma fácil manutenção, um controlo de acesso e maior legibilidade. Por estas mesmas razões, nós retirámos os endereços das respectivas construções de po.xsd, e inserimo-las num novo ficheiro chamado address.xsd. O ficheiro do esquema da nota de encomenda que foi modificado chama-se ipo.xsd:

Exemplo
O Esquema da Nota de Encomenda Internacional, ipo.xsd
<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

  <annotation>
    <documentation xml:lang="en">
      Esquema da Nota de Encomenda Internacional para [Example.com]
      Copyright 2000 Example.com. Todos os direitos são reservados!
    </documentation>
  </annotation>

  <!-- include address constructs -->
  <include
    schemaLocation="http://www.example.com/schemas/address.xsd"/>

  <element name="purchaseOrder" type="ipo:PurchaseOrderType"/>

  <element name="comment" type="string"/>

  <complexType name="PurchaseOrderType">
    <sequence>
      <element name="shipTo"     type="ipo:Address"/>
      <element name="billTo"     type="ipo:Address"/>
      <element ref="ipo:comment" minOccurs="0"/>
      <element name="items"      type="ipo:Items"/>
    </sequence>
    <attribute name="orderDate" type="date"/>
  </complexType>

  <complexType name="Items">
    <sequence>
      <element name="item" minOccurs="0" maxOccurs="unbounded">
        <complexType>
          <sequence>
            <element name="productName" type="string"/>
            <element name="quantity">
              <simpleType>
                <restriction base="positiveInteger">
                  <maxExclusive value="100"/>
                </restriction>
              </simpleType>
            </element>
            <element name="USPrice"    type="decimal"/>
            <element ref="ipo:comment" minOccurs="0"/>
            <element name="shipDate"   type="date" minOccurs="0"/>
          </sequence>
          <attribute name="partNum" type="ipo:SKU" use="required"/>
        </complexType>
      </element>
    </sequence>
  </complexType>

  <simpleType name="SKU">
    <restriction base="string">
      <pattern value="\d{3}-[A-Z]{2}"/>
    </restriction>
  </simpleType>

</schema>

O ficheiro que contém a construção do endereço intitula-se:

A várias notas de encomenda e construções dos endereços estão agora contidas em dois ficheiros contendo os referidos esquemas, nomeadamente ipo.xsd e address.xsd. Para considerar essas mesmas construções como parte da nota de encomenda internacional, ou seja, para incluí-las no espaço-nominal da nota de encomenda, ipo.xsd terá de conter o elemento include:

Exemplo
<include schemaLocation="http://www.example.com/schemas/address.xsd"/>

O propósito do uso deste elemento include é o de integrar as definições e declarações contidas em address.xsd e torná-las disponíveis como parte do espaço-nominal de destino da nota de encomenda internacional. A única regra de oiro a respeitar no uso do elemento include será que o espaço-nominal dos elementos nele contidos seja igual ao espaço-nominal de destino do esquema inclusivo, o qual corresponde neste caso a http://www.example.com/IPO. Ao se integrarem essas definições e declarações, através do uso do mecanismo include, adicionam-se efectivamente os seus componentes ao espaço-nominal de destino.No Capítulo Redefinindo Tipos e Grupos (§4.5), nós descrevemos um mecanismo similar, o qual permite que você modifique alguns elementos sempre que eles sejam integrados.

No nosso caso, nós exibimos apenas um documento do tipo [including (incluíndo)] e um documento do tipo [included (incluído)]. Na prática é possível incluir mais do que um documento, usando elementos include múltiplos e além disso os documentos podem incluir documentos, os quais incluem por sua vez outros documentos. Contudo, o encaixamento dos documentos desta forma será apenas legal se todas as partes do esquema neles incluídas forem declaradas com o mesmo espaço-nominal de destino.

Os documentos de instância que estejam em conformidade com os esquemas cujas definições cubram os documentos contendo esquemas múltiplos necessitam apenas de referenciar o documento mais destacado e o espaço-nominal comum, sendo da responsabilidade do processador o acto de unir ou unir todas as definições especificadas nos vários documentos do tipo [included]. No exemplo de cima, o documento de instância ipo.xml (ver Usando os Tipos Derivados nos Documentos de Instância (§4.3)) referencia apenas o espaço-nominal de destino comum a todos, http://www.example.com/IPO, e (por implicação) o ficheiro com o esquema http://www.example.com/schemas/ipo.xsd. O processador é o responsável pela obtenção do ficheiro com o esquema address.xsd.

No Capítulo Importando os Tipos (§5.4), nós descrevemos a forma como os esquemas poderão ser usados, de forma a validarem o conteúdo de mais do que um espaço-nominal.

previous sub-section next sub-section4.2 Derivando Tipos Complexos por Extensão

Para criar as construções do endereço, nós começamos por criar um tipo complexo chamado Address , da maneira usual (ver address.xsd). O tipo Address contém os elementos básicos de um endereço: um nome, uma rua e uma cidade. (Esta definição é capaz de não funcionar em todos os países, mas serve o propósito do exemplo que nós pretendemos aqui dar.) Partindo deste ponto, nós derivamos dois tipos complexos novos que contenham todos os elementos do tipo original mais os elementos adicionais que são especificados para os endereços nos USA e GB. A técnica que nós utilizámos aqui para derivar novos tipos de endereço (complexos), através da extensão ou prolongamento de um tipo já existente, é a mesma técnica que nós utilizámos no Capítulo Tipos Complexos a partir dos Tipos Simples (§2.5.1), à excepção que aqui o nosso tipo básico é um tipo complexo, ao passo que na secção anteriormente mencionada se tratava de um tipo simples.

Nós definimos os dois novos tipos complexos, USAddress e UKAddress, usando o elemento complexType. A somar a essa acção, nós indicámos que os modelos do conteúdo destes novos tipos são complexos, ou seja que contêm elementos, através do uso do elemento complexContent, e ainda que nós procedemos à extensão ou ao prolongamento do tipo básico Address através da aplicação do valor do atributo base no elemento extension.

Quando um tipo complexo é derivado por extensão, o seu modelo de conteúdo efectivo é o modelo de conteúdo do tipo básico mais o modelo de conteúdo especificado na derivação do respectivo tipo. Além disso, estes dois modelos de conteúdo são tratados como derivadas de um grupo sequencial. No caso de UKAddress, o modelo do conteúdo de UKAddress é o modelo do conteúdo de Address mais as declarações do elemento postcode e do atributo exportCode. Isto significa quase definir o elemento UKAddress a partir do princípio:

previous sub-section next sub-section4.3 Usando os Tipos Derivados nos Documentos de Instância

No cenário do nosso exemplo, as notas de encomenda são geradas como resposta aos pedidos dos clientes, os quais poderão envolver endereços de envio e de cobrança em diversos países. A nota de encomenda internacional, ipo.xml, a qual é mais abaixo exemplificada, ilustra um desses casos em que os bens são enviados para o Reino Unido e a respectiva cobrança para um endereço dos USA. Claro que será melhor se no esquema das notas de encomenda internacionais não se tiver de definir detalhadamente cada combinação possível dos endereços internacionais de envio e de cobrança, ainda mais se nós podermos adicionar novos tipos complexos de endereços internacionais simplesmente através da criação do elemento Address.

O Esquema XML permite-nos definir os elementos billTo e shipTo na qualidade de tipos Address (ver ipo.xsd) , tendo no entanto de se usar as instâncias dos endereços internacionais em vez das instâncias do elemento Address. Por outras palavras, um documento de instância cujo conteúdo esteja em conformidade com o tipo UKAddress será considerado válido se esse conteúdo aparecer representado no documento, na mesma localização onde o elemento Address é esperado (assumindo aqui que o conteúdo do elemento UKAddress seja válido). Para fazermos com que esta característica do Esquema XML funcione, e para identificarmos exactamente qual o tipo de derivada pretendida, o tipo de derivada deverá ser identificado no documento de instância. O tipo é identificado pelo uso do atributo xsi:type o qual faz parte do espaço-nominal da instância do Esquema XML. No próximo exemplo, ipo.xml, o uso dos tipos derivados UKAddress e USAddress é identificado através dos valores definidos para os atributos xsi:type.

No Capítulo Controlando o Uso e a Criação dos Tipos Derivados (§4.8), nós descrevemos como se poderá evitar que os tipos derivados sejam utilizados neste tipo de substituição.

previous sub-section next sub-section4.4 Derivando os Tipos Complexos por Restrição

A somar ao método de derivação de novos tipos complexos através da extensão ou do prolongamento dos modelos dos conteúdos, é ainda possível derivar novos tipos através da restrição dos modelos de conteúdos dos tipos já existentes. A restrição dos tipos complexos é conceitualmente igual à restrição dos tipos simples, excepto que a restrição dos tipos complexos envolvem o tipo de declaração em vez de envolver uma escala de valores aceitáveis para o tipo simples. Um tipo complexo que seja derivado por restrição é bastante similar ao seu tipo básico, excepto que a sua declaração é mais limitada do que as declarações correspondentes aos tipos básicos (a partir dos quais ele foi derivado). De facto, os valores representados pelo novo tipo são respectivamente um sub-conjunto dos valores representados pelo tipo básico (como é o caso como é o caso com a limitação dos tipos simples). Por outras palavras, uma aplicação que seja preparada para os valores do tipo básico não será surpreendida ou importunada pelos valores de um tipo limitado.

Suponhamos por exemplo, que nós pretendemos actualizar a definição da nossa nota de encomenda, de forma que ela necessite assim de conter o elemento comment; o esquema que nos é exibido em ipo.xsd permite que um elemento do tipo purchaseOrder apareça sem quaisquer derivadas do tipo comment Para criarmos o nosso novo tipo RestrictedPurchaseOrderType [NotadeEncomendaRestringida], nós definimo-lo da forma habitual, indicando que ele foi derivado pela restrição do tipo simples PurchaseOrderType, e atribuímos-lhe um novo valor (mais restringente) para o número mínimo de ocorrências do elemento comment. Note no entanto que os tipos derivados por restrição deverão conter a repetição de todos os componentes das partículas (declarações dos elementos, grupos de modelos e wildcards) da definição do tipo básico a ser incluída no tipo de derivada. Contudo, as declarações dos atributos não necessitam de ser repetidas na definição do tipo derivado; neste caso, o elemento RestrictedPurchaseOrderType herdou a declaração do atributo orderDate pertencente a PurchaseOrderType.

Esta alteração delimita o número aceitável de elementos comment de 0 (mínimo) até 1. Note-se que todos os elementos do tipo RestrictedPurchaseOrderType também serão aceites como sendo elementos do tipo PurchaseOrderType .

Com vista a uma melhor ilustração das restrições, no Quadro 3 ser-lhe-ão exibidos vários exemplos de como as declarações dos elementos e atributos poderão ser limitadas dentro das definições dos tipos (o quadro mostra-nos a sintaxe dos elementos embora os três primeiros exemplos sejam igualmente restrições válidas para os atributos).

Quadro 3. Exemplos de Restrições
Restrições Básicas Notas
default="1" estipular um valor por defeito, onde não se tenha atribuído ainda nenhum valor
fixed="100" estipular um valor efectivo, onde não tenha ainda atribuído nenhum valor
type="string" especificando um tipo, onde não se tenha ainda especificado nenhum
(minOccurs, maxOccurs) (minOccurs, maxOccurs)
(0, 1) (0, 0) exclusão de um elemento opcional; esta acção também poderá ser concluída através da omissão da declaração dos componentes da definição do tipo que foi restrito ou limitado
(0, 1) (1, 1) a criação de um elemento opcional requer
(0, ilimitado)
(0, 0)
(0, 37)
(1, 37)
(1, 9)
(1, 8)
(2, 9)
(4, 7)
(3, 3)
(1, ilimitado)
(1, 12)
(3, ilimitado)
(6, 6)
(1, 1) (1, 1) não se podem restringir minOccurs ou maxOccurs

previous sub-section next sub-section4.5 Redefinindo Tipos e Grupos

No Capítulo O Esquema em Documentos Múltiplos ou Variados (§4.1), nós descrevemos a forma como incluir as definições e as declarações obtidas a partir de ficheiros de esquemas externos contendo o mesmo espaço-nominal de destino. O mecanismo include permite-nos o uso de componentes do esquema criados externamente do tipo "as-is", ou seja, sem qualquer tipo de modificação. Acabámos de descrever a forma como derivar os novos tipos, por extensão e por restrição. O mecanismo redefine que nós descrevemos aqui pemite-nos a redifinição de tipos simples e complexos, de grupos e de grupos de atributos que sejam obtidos a partir de ficheiros de esquemas externos. Tal como no caso do mecanismo include, redefine requer que os componentes externos estejam contidos no mesmo espaço-nominal de destino que os esquemas a redifinir, se bem que os componentes externos dos esquemas que não possuam qualquer espaço-nominal também possam ser redefinidos. Neste último caso, os componentes que foram redefinidos recebem uma parte do espaço-nominal de destino do esquema a redifinir.

De forma a ilustrarmos aqui o mecanismo redefine, nós usamo-lo em vez do mecanismo include, O Esquema da Nota de Encomenda Internacional, ipo.xsd, de forma a podermos modificar a definição do tipo complexo Address, contido em address.xsd:

O elemento redefine actua de uma forma bastante semelhante à do elemento include, dado que ele inclui todas as declarações e definições do ficheiro address.xsd. A definição do tipo complexo Address usa o já conhecido sintaxe de extensão para adicionar o elemento country à definição de Address. Note-se aqui contudo, que Address é também o tipo básico. Fora do elemento redefine, qualquer tentativa para definir um tipo complexo com o mesmo nome (e contido dentro do mesmo espaço-nominal), como a base a partir do qual ele está a ser derivado, provocaria um erro. Mas neste caso não existe qualquer erro e a definição por extenso de Address recebe a única definição de Address.

Agora que o elemento Address já foi redefinido, a é-se aplicada a extensão a todos os componentes do esquema que façam uso de Address. Por exemplo, address.xsd contém definições de tipos de endereços internacionais, os quais são derivados a partir de Address. Essas definições reflectem o tipo já redefinido Address, como nos é aqui mostrado no próximo fragmento:

Exemplo
Fragmento do ficheiro ipo.xml utilizando um Endereço Redefinido
 ....
 <shipTo exportCode="1" xsi:type="ipo:UKAddress">
   <name>Helen Zoe</name>
   <street>47 Eden Street</street>
   <city>Cambridge</city>
   <!-- country was added to Address which is base type of UKAddress -->
   <country>Reino Unido</country>
   <!-- postcode was added as part of UKAddress -->
   <postcode>CB1 1JR</postcode>
 </shipTo>
 ....

O nosso exemplo foi cuidadosamente construído, de maneira a que o tipo que foi redefinido, Address, não entre de forma alguma em conflito com os tipos que foram derivados da definição original de Address. Note ainda que é bastante fácil criar aqui um conflito. Por exemplo, se as derivações do tipo de endereço internacional tiverem expandido o elemento Address somando-lhes o elemento country, então a redefinição de Address consistiria na soma de um elemento com o mesmo nome ao conteúdo do modelo de Address. Dois elementos com o mesmo nome não serão aqui permitidos (ou que estejam contidos no mesmo espaço-nominal), apenas tipos diferentes poderão estar contidos num modelo de conteúdo, de forma que qualquer tentativa para redefinir Address iriam provocar um erro. Em geral, o elemento redefine não nos protege de tais erros, devendo ser cautelosamente utilizado.

previous sub-section next sub-section4.6 Grupos de Substituição

O Esquema XML fornece-nos um mecanismo intitulado de grupos de substituição, o qual permite que os elementos possam ser substituídos por outros elementos. Falando de uma forma mais detalhada, os elementos poderão ser definidos para um grupo especial de elementos, os quais se pressupõe serem substituíveis por elementos particularmente nomeados de elementos de cabeçalho. (Note que os elementos de cabeçalho, tal como os eleemntos substituíveis deverão ser declarados na qualidade de elementos globais.) Para ilustrar este caso, nós declarmos dois elementos, intitulados customerComment e shipComment e designámo-los para um grupo de substituição, cujo elemento de cabeçalho é comment, de forma que tanto customerComment como shipComment poderão ser utilizados em qualquer um dos sítios onde nós possamos utilizar comment. Os elementos contidos num grupo de substituição deverão possuir o mesmo tipo que o elementos do cabeçalho ou ainda um tipo que tenha sido derivado do tipo do elemento do cabeçalho. Para declarar esses dois novos elementos e para os tornar substituíveis pelo elemento comment, nós utilizamos o seguinte sintaxe:

Sempre que estas declarações sejam adicionadas ao esquema da nota de encomenda internacional, os elementos shipComment e customerComment poderão ser substituídos pelo elemento comment no documento de instância, por exemplo:

Exemplo
Fragmento do ficheiro ipo.xml contendo Elementos Substituídos
....
<items>
  <item partNum="833-AA">
    <productName>Lapis necklace</productName>
    <quantity>1</quantity>
    <USPrice>99.95</USPrice>
    <ipo:shipComment>
      Use gold wrap if possible
    </ipo:shipComment>
    <ipo:customerComment>
      Preciso deste produto agora para as férias!
    </ipo:customerComment>
    <shipDate>1999-12-05</shipDate>
  </item>
</items>
....

Note que, sempre que um documento de instância contêr substituições de elementos cujos tipos sejam derivados a partir dos seus elementos de cabeçalhos não será necessário identificar os tipos derivados, usando a construção xsi:type que nós descrevemos no Capítulo Usando os Tipos Derivados nos Documentos de Instância (§4.3).

A existência de um grupo de substituição não requer que qualquer um dos elementos contidos nessa classe sejam utilizados, nem tão-pouco excluirá a hipótese de se utilizar o elemento de cabeçalho. Ele fornece-nos simplesmente um mecanismo, o qual permite que os elementos sejam utilizados de uma forma intercâmbial.

previous sub-section next sub-section4.7 Tipos e elementos abstractos

O Esquema XML fornece-nos um mecanismo de forma a forçar a substituição de certo tipo de elementos. Quando um tipo ou elemento for declarado como "abstracto", ele não poderá ser utilizado num documento de instância. Quando o elemento fôr declarado como abstracto, um dos membros pertencentes ao grupo de substituição desse elemento deverá aparecer referido no documento de instância. Quando a definição do tipo correspondente ao elemento fôr declarada abstracta, todas as instâncias desse elemento deverão usar o atributo xsi:type, a fim de indicar os tipos derivados que não sejam abstractos.

Relativamente ao exemplo do grupo de substituição que descrevemos em Grupos de substituição (§4.6), ser-nos-ia útil impedir específicamente o uso de elementos comment, de forma a que a instância faça assim o uso obrigatório dos elementos customerComment e shipComment. Para se declarar o elemento abstracto comment, nós modificámos as suas declarações originais contidas no esquema da nota de encomenda internacional, ipo.xsd, como no exemplo que se segue:

Exemplo
<element name="comment" type="string" abstract="true"/>

Com o elemento comment declarado na qualidade de abstracto, as instâncias das notas de encomendas internacionais são agora apenas válidas se contiverem os elementos customerComment e shipComment.

Declarar um elemento como abstracto requer o uso de um grupo de substituição. Declarar um tipo como sendo abstracto, requer simplesmente o uso do tipo que foi dele derivado (e identificado pelo atributo xsi:type) no documento de instância. Consideremos agora a seguinte definição de esquema:

O elemento transport não é abstracto, por isso ele pode aparecer nos documentos de instância. Contudo, uma vez que a definição do seu tipo corresponde é abstracta (o tipo é abstracto), ele nunca poderá aparecer num documento de instância sem ser acompanhado de um atributo xsi:type, o qual se refere a um tipo derivado. Isso significa que o seguinte esquema não é válido como esquema:

Exemplo
<transport xmlns="http://cars.example.com/schema"/>

porque o tipo do elemento transport é abstracto. Contudo, o seguinte esboço é válido dentro do esquema:

Exemplo
<transport xmlns="http://cars.example.com/schema"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:type="Car"/>

porque ele usa um tipo não abstracto o qual é substituível por Vehicle.

previous sub-section 4.8 Controlando o Uso e a Criação dos Tipos Derivados

Até aqui, nós fomos capazes de derivar novos tipos e de utilizá-los em documentos de instância sem qualquer tipo de restrições.Em realidade, os autores de esquemas quererão controlar as derivações de determinados tipos, bem como o uso dos tipos derivados nas instâncias.

O Esquema XML fornece-nos um par de mecanismos que controlam a derivação dos tipos. Um desses mecanismos permite ao autor do esquema especificar que, relativamente a um tipo complexo em particular, novos tipos poderão não ser derivados a partir dele, quer seja por restrição, (b) por extensão, ou (c) de forma alguma. Para ilustrar este caso, suponhamos que nós queremos evitar qualquer derivação por restrição do tipo Address, dado que nós pretendemos que ele seja apenas utilizado como base para os tipos prolongados, como por exemplo USAddress e UKAddress. Para prever assim qaulquer uma dessas derivações, nós alterámos ligeiramente a definição original de Address, como no exemplo que se segue:

O valor restriction, pertencente ao atributo final, impede as derivações dos tipos por restrição. A prevenção das derivações de forma alguma, ou por extensão, é-nos respectivamente indicada pelos valores #all e extension. Existe ainda um atributo opcional, finalDefault, contido no elemento schema, cujo valor poderá ser um dos valores permitidos para o atributo final. O efeito obtido pela especificação do atributo finalDefault é igual ao efeito obtido pela especificação do atributo final em cada definição de tipo e declaração de elementos contidos no esquema.

Um outro mecanismo de controlo da derivação de tipos, cujas propriedades poderão ser aplicadas na derivação de um novo tipo simples. Quando um novo tipo é definido, o atributo fixed poderá ser aplicado a cada uma das suas propriedades (facets) de forma a prevenir que a derivação desse tipo modifique o valor das propriedades fixas (facets). Nós poderemos por exemplo definir o tipo simples Postcode da seguinte forma:

Uma vez que este tipo simples tenha sido definido, nós poderemos derivar um novo tipo de código postal, no qual nós aplicaremos uma propriedade (facet) não fixa á definição da base, por exemplo:

De qualquer das maneiras, nós não poderemos derivar um novo código postal no qual nós voltamos a aplicar uma qualquer propriedade estabelecida na definição da base:

Em adição ao mecanismo que controla as derivações dos tipos, o Esquema XML fornece-nos ainda um mecanismo que controla quais os grupos de derivação e de substituição que poderão ser utilizados nos documentos de instância. No Capítulo Usando Tipos Derivados nos Documentos de Instância (§4.3), nós descrevemos a forma como os tipos derivados, USAddress e UKAddress, poderiam ser usados pelos elementos shipTo e billTo nos documentos de instância. Esses tipos derivados podem substituir o modelo de conteúdo fornecido pelo tipo Address, uma vez que eles são derivados a partir do tipo Address. Contudo, as substitições efectuadas pelos tipos derivados podem ser controladas, através do uso do atributo block, na definição do tipo. Por exemplo, se nós quisermos impedir que qualquer uma das derivações por restrição seja usada em vez de Address (talvez pela mesma razão que nós definimos Address com o atributo final="restriction"), nós poderemos alterar a definição original de Address, como no exemplo que se segue:

O valor de restrição contido no atributo block evita que as derivações por restrição substituiam o elemento Address na instância. Isso não evitará contudo que UKAddress e USAddress substituiam Address, uma vez que eles são derivados por extensão. A prevenção das derivações de forma alguma, ou por por extensão, é-nos respectivamente indicada pelos valores #all e extension. Tal como no caso do atributo final, existe um atributo opcional blockDefault contido no elemento schema, cujo valor poderá ser um dos valores permitidos para o atributo block. O efeito obtido pela especificação do atributo blockDefault é equivalente ao efeito obtido pela especificação do atributo block em cada definição de tipo e declaração de elementos contidos no esquema.

5 Conceitos Avançados III: O Relatório Trimestral

O efectuamento dos pedidos e a sua facturação podem gerar relatórios ad-hoc que sumarizem a quantidade de cada tipo de produto que foi facturada para cada uma das regiões base. Um exemplo de tal relatório, cobrindo o quarto trimestre de 1999, é-nos exibido no ficheiro 4Q99.xml.

Note-se que nesta secção nós usámos elementos qualificados no esquema e que os espaços-nominais por defeito eram possibilitados nas instâncias.

Neste relatório são listados, de acordo com o seu número e a sua quantidade, as partes facturadas pelos vários códigos postais, fornecendo-nos ainda a descrição de cada uma das partes mencionadas. Ao sumariar a factura, a intenção do relatório é clara e os dados não são ambíguos, dado que existem umas quantas restrições. Por exemplo, cada código postal aparece apenas uma vez (restrição de unicidade). Similarmente, a descrição de cada uma das partes facturadas aparece apenas uma vez, se bem que essas partes possam ser facturadas para vários códigos postais (restrição referencial), como por exemplo a parte número 455-BX. Nas próximas secções, nós analisaremos a forma como especificar essas restrições usando o Esquema XML.

Exemplo
O Esquema do Relatório, report.xsd
<schema targetNamespace="http://www.example.com/Report"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:r="http://www.example.com/Report"
        xmlns:xipo="http://www.example.com/IPO"
        elementFormDefault="qualified">

  <!-- for SKU -->
  <import namespace="http://www.example.com/IPO"/>

  <annotation>
    <documentation xml:lang="en">
      Esquema do Relatório de Example.com
      Copyright 2000 Example.com. Todos os direitos são reservados!
    </documentation>
  </annotation>

  <element name="purchaseReport">
    <complexType>
      <sequence>
        <element name="regions" type="r:RegionsType"/>

        <element name="parts" type="r:PartsType"/>
      </sequence>
      <attribute name="period"       type="duration"/>
      <attribute name="periodEnding" type="date"/>
    </complexType>

    <unique name="dummy1">
      <selector xpath="r:regions/r:zip"/>
      <field xpath="@code"/>
    </unique>

    <key name="pNumKey">
      <selector xpath="r:parts/r:part"/>
      <field xpath="@number"/>
    </key>

    <keyref name="dummy2" refer="r:pNumKey">
      <selector xpath="r:regions/r:zip/r:part"/>
      <field xpath="@number"/>
    </keyref>

  </element>

  <complexType name="RegionsType">
    <sequence>
      <element name="zip" maxOccurs="unbounded">
        <complexType>
          <sequence>
            <element name="part" maxOccurs="unbounded">
              <complexType>
                <complexContent>
                  <restriction base="anyType">
                    <attribute name="number"   type="xipo:SKU"/>
                    <attribute name="quantity" type="positiveInteger"/>
                  </restriction>
                </complexContent>
              </complexType>
            </element>
          </sequence>
          <attribute name="code" type="positiveInteger"/>
        </complexType>
      </element>
    </sequence>
  </complexType>

  <complexType name="PartsType">
    <sequence>
      <element name="part" maxOccurs="unbounded">
        <complexType>
          <simpleContent>
            <extension base="string">
              <attribute name="number" type="xipo:SKU"/>
            </extension>
          </simpleContent>
        </complexType>
      </element>
    </sequence>
  </complexType>

</schema>

next sub-section5.1 Especificando as Unicidades

O Esquema XML permite-nos indicar que cada valor dos elementos ou atributos deverá ser único dentro de um certo contexto. Para indicar que o valor de um determinado atributo ou elemento é único, nós usamos primeiramente o elemento unique, com a finalidade de "seleccionar" um grupo de elementos, identificando de seguida o atributo ou o elemento "field" correspondente a cada um dos elementos seleccionados, os quais deverão ser únicos no mesmo âmbito do conjunto dos elementos que foram seleccionados. No caso do esquema do nosso relatório, report.xsd, o atributo do elemento selector denominado xpath, contém uma expressão XPath, r:regions/r:zip, a qual selecciona a lista de todos elementos zip contidos num relatório de instância. De igual forma, o atributo do elemento field, denominado xpath, contém uma segunda expressão XPath, @code, a qual especifica que os valores do atributo code correspondente a esses elementos deverá ser único. Note que os elementos das expressões XPath limitam o espaço de tuod aquilo que tenha de ser único. O relatório poderá conter um outro atributo do tipo code, mas o seu valor não terá de ser único, dado que ele se encontra fora do espaço definido pelas expressões correspondentes a XPath. Note ainda que as expressões XPath que você possa usar no atributo xpath estão limitadas a um subconjunto da linguagem Xpath, definida em XML Path Language 1.0.

Nós também poderemos indicar combinações de campos que tenham de ser únicos. Voltando agora ao exemplo da nossa nota de encomenda, suponhamos que nós pretendemos que cada item contenha uma combinação única constituída pelo número e nome do produto. Nós poderíamos conseguir obter tal restrição, especificando que a combinação dos valores dos atributos partNum e da sua derivada productName deverá ser única em cada um dos elementos item.

Para definir combinações de valores, nós recorremos simplesmente ao uso múltiplo de elementos field, com o fim de identificar todos os valores nelas envolvidos:

previous sub-section next sub-section5.2 Definindo as Teclas-chave e as suas Referências

No relatório trimestral de 1999, a descrição de cada uma das partes facturadas aparece apenas uma vez. Nós poderíamos reforçar esta restrição usando o elemento unique, contudo, nós também queremos assegurar que cada elemento pertencente à parte da quantidade, listado sob um determinado código postal contenha uma parte correspondente à descrição. Nós reforçamos assim a referida restrição, usando os elementos key e keyref. O esquema do relatório, report.xsd, mostra-nos que as construções key e keyref são aplicadas usando quase sempre o mesmo sintaxe que o elemento unique. O elemento chave é aplicado ao valor do atributo number contido nos elementos part, derivados do elemento parts. Esta declaração de number, considerada aqui como chave, significa que o seu valor deve ser único e que não pode ser definido como nulo (0), e ainda que o nome que é associado com o elemento chave, nomeadamente pNumKey, faz com que ele seja referênciável num outro lugar qualquer.

Para assegurar que os elementos referentes à parte da quantidade possuem a correspondente parte descritiva, nós dizemos que o atributo number ( ) desses elementos ( ) deverá referenciar o elemento chave pNumKey. Esta declaração de number na qualidade de keyref, não significa que o seu valor tenha de ser único, mas também não significa que tenha de existir um elemento pNumKey com o mesmo valor.

Tal como você terá percebido através da comparação com o elemento unique, é possível definir combinações dos valores dos elementos key e keyref. Usando este mecanismo, nós poderemos ir um pouco além, requindo que os números dos produtos sejam iguais e definindo uma combinação de valores que tenha de ser igual. Tais valores poderão envolver combinações de tipos com valores múltiplos (string, integer, date, etc.), assegurando dessa forma que a ordem e o tipo das referências do elemento field sejam iguais nas definições correspondentes a key e a keyref.

previous sub-section next sub-section5.3 Restrições do Esquema XML (x) Atributos ID do XML 1.0

XML 1.0 fornece-nos um mecanismo que nos assegura a unicidade, através da utilização do atributo de ID e seus atributos (IDREF e IDREFS). Este mecanismo também nos é fornecido no Esquema XML, através dos tipos simples ID, IDREF e IDREFS, os quais podem ser usados para a declaração dos atributos do estilo XML 1.0. O Esquema XML também introduz novos mecanismos que são mais flexiveis e eficientes. Por exemplo, os mecanismos dos Esquemas XML poderão ser aplicados a qualquer conteúdo de atributos ou elementos, sem atender ao eu tipo. Pelo contrário, ID é um tipo de atributo e por isso não poderá ser aplicado a outros atributos, a elementos ou ao seu conteúdo. Além disso, este Esquema permite-lhe que você especifique o espaço no qual a unicidade é aplicada, ao passo que o espaço de um atributo ID é definido como sendo o documento inteiro. Finalmente, o Esquema permite-nos criar elementos keys ou keyref, a partir das combinações do conteúdo do elemento e do atributo, ao passo que ID não possui tal facilidade.

previous sub-section next sub-section5.4 Importando Tipos

O esquema do relatório, report.xsd, serve-se de um tipo simples, xipo:SKU , que é definido num outro esquema e num outro espaço-nominal de destino. Lembremo-nos aqui que nós utilizámos o elemento include de forma a que o esquema contido em ipo.xsd pudesse fazer uso das declarações e definições contidas em address.xsd. Nós não podemos usar aqui o elemento include, uma vez que ele só se pode extrair das definições e das declarações de um esquema cujo espaço-nominal de destino seja o mesmo que o espaço-nominal de destino inclusivo. Daí que, o elemento include não identifica o espaço-nominal (embora ele requira um elemento schemaLocation). O mecanismo de importação que nós descrevemos nesta secção é um importante mecanismo que possibilita que os componentes provindos de espaços-nominais de destino diferentes possam ser usados conjuntamente, possibilitando assim a validação no esquema de contéudos de instância defindos através de espaços-nominais múltiplos.

Para importar o tipo SKU e usá-lo no esquema do relatótio, nós temos de identificar o espaço-nominal no qual SKU está definido e associar o seu espaço-nominal a um prefixo que o permita usar no referido relatório. Mais concretamente, nós usamos o elemento import para identificar o espaço-nominal de destino de SKU, nomeadamente http://www.example.com/IPO, e associamos o espaço-nominal de destino ao prefixo xipo usando uma declaração standard do espaço-nominal. O tipo simples SKU, definido no espaço-nominal http://www.example.com/IPO, poderá então ser referenciado como xipo:SKU em qualquer uma das definições e declarações do esquema do relatório.

No nosso exemplo, nós importámos um tipo simples a partir de um espaço-nominal externo e utilizámo-lo para declarar atributos. O Esquema XML permite-nos de facto importar múltiplos componentes do esquema a partir de múltiplos espaços-nominais, podendo também eles ser referidos em ambas as declarações e definições. Por examplo, em report.xsd, nós poderíamos adicionalmente re-utilizar o elemento comment, declarado em ipo.xsd, através da sua referência numa declaração:

Exemplo
<element ref="xipo:comment"/>

Note contudo, que nós não poderemos re-utilizar o elemento shipTo contido em ipo.xsd e que o esquema seguinte não é legal dado que apenas os componentes dos esquemas globais poderão ser importados:

Exemplo
<element ref="xipo:shipTo"/>

Em ipo.xsd, comment é declarado como sendo um elemento global, por outras palavras, ele é declarado como sendo um elemento pertencente a schema. Contráriamente a esse caso, o elemento shipTo é declarado localmente, ou seja, ele é um elemento declarado dentro de uma definição do tipo complexo, nomeadamente do tipo PurchaseOrderType.

Os tipos complexos também podem ser importados, podendo apenas ser utilizados como os tipos base para a derivação de novos tipos. Apenas os tipos complexos que possuam um nome poderão ser importados: os tipos locais, anónimamente definidos, não o podem. Suponham que nós queremos incluir o nome de um analista no nosso relatório, lado a lado com a informação do contacto. Nós podemos re-utilizar o tipo complexo (globalmente definido) USAddress a partir de address.xsd, e extendê-lo de forma a definir um novo tipo chamado Analyst no esquema do relatório, adicionando os novos elementos phone e email:

Usando este novo tipo, nós declaramos o elemento chamado analyst, como sendo parte da declaração do elemento purchaseReport (a declaração não é exibida) no esquema do relatório.Assim, o documento de instância que agora se segue, estaria em conformidade com o esquema do relatório que foi modificado:

Note que o relatório contém agora tanto os elementos qualificados como os elementos não qualificados. Isto dá-se ao facto dos elementos (name, street, city, state e zip) serem localmente declarados em ipo.xsd, cujo elemento elementFormDefault é definido como unqualified (por defeito). Os outros elementos contidos no examplo, são declarados em report.xsd, cujo elemento elementFormDefault é definido como qualified (qualificado).

Sempre que os componentes dos esquemas sejam importados a partir de vários espaços-nominais, cada espaço-nominal deverá ser identificado com um elemento import em separado. Os elementos do tipo import deverão eles próprios aparecer como primeira derivada do elemento schema. Além disso, a cada espaço-nominal deverá ser associado um prefixo. Para isso utiliza-se uma declaração standard do espaço-nominal e um prefixo para qualificar as referências a qualquer um dos componentes do esquema pertencentes a esse espaço-nominal. Para finalizar, os elementos import contêm opcionalmente o atributo schemaLocation, para ajudar a localizar os recursos associados aos espaços-nominais. Nós discutiremos o atributo schemaLocation mais detalhadamente, numa secção posterior.

5.4.1 As Livrarias com os variados Tipos

À medida que os esquemas XML se tornam mais difundidos, os seus autores pretenderão criar tipos simples e complexos que possam ser partilhados e utilizados como blocos de construção na criação de novos esquemas. Os Esquemas XML fornecem-nos os tipos que desempenham esse papel, particularmente os tipos descritos no Apêndice dos Tipos Simples e no Capítulo introdutório referente à Livraria com os variados Tipos.

Os autores dos esquemas quererão indubitávelmente criar as suas próprias livrarias de tipos, com vista a representar as unidades monetárias, unidades de medida, endereços de negócios, e por aí adiante. Cada uma dessas livrarias poderá consistir num esquema contendo uma ou mais definições, como por exemplo, um esquema contendo um tipo de unidade monetária:

Exemplo de um elemento aparecendo numa instância e possuíndo este tipo:

Exemplo
<convertFrom name="AFA">199.37</convertFrom>

Depois de termos definido o tipo da unidade monetária corrente, nós poderemos disponibilizar a sua re-utilização em outros esquemas, através do mecanismo import que acabámos de descrever.

previous sub-section next sub-section5.5 Qualquer Elemento, Qualquer Atributo

Nas secções anteriores, nós observamos vários mecanismos destinados extensão dos modelos de conteúdos dos tipos complexos. Por exemplo, um modelo de conteúdo misto poderá conter dados de carácter arbitrário adicionados aos elementos, ou por exemplo, o modelo de um conteúdo poderá conter elementos cujos tipos sejam importados a partir de espaços-nominais externos. De qualquer das maneiras, esses mecanismos fornecem controlos, respectivamente, muito alargados ou muito estreitos. O propósito desta secção é o de descrever um mecanismo flexível que permita que os modelos dos conteúdos possam ser extensos por qualquer dos elementos e atributos pertencentes a espaços-nominais especificados.

Para ilustrar este exemplo, consideremos uma versão do relatório trimestral 4Q99html.xml, no qual nós encaixámos uma representação XHTML correspondente às partes dos dados XML. O conteúdo XHTML aparece como sendo o conteúdo do elemento htmlExample, e o espaço-nominal por defeito é alterado no elemento XHTML mais exterior (table) de forma a que todos os elementos XHTML pertençam ao espaço-nominal XHTML, http://www.w3.org/1999/xhtml:

De forma a permitir a aparição de XHTML no documento de instância, nós modificamos o relatório do esquema, declarando o novo elemento htmlExample, cujo conteúdo é definido pelo elemento any [qualquer]. De uma forma geral, o elemento any especifica que qualquer XML que tenha sido bem construído ou estruturado será permitido no modelo do conteúdo do tipo. Neste exemplo, nós requeremos que XML pertença ao espaço-nominal http://www.w3.org/1999/xhtml, por outras palavras, ele tem ou deverá ser XHTML. Este exemplo também requer que exista nele pelo menos um elemento pertencente a este espaço-nominal, como é indicado pelos valores de minOccurs e maxOccurs:

A modificação permite que alguns XML bem construídos, pertencentes ao espaço-nominal http://www.w3.org/1999/xhtml, apareçam dentro do elemento htmlExample. Por isso mesmo, o uso de 4Q99html.xml é permissível, dado que existe um elemento (conjuntamente com a sua derivada) que é bem formado, o elemento aparece contido no elemento apropriado (htmlExample), e o documento de instância estipula que o elemento e o sue conteúdo pertençam ao espaço-nominal requerido. Contudo, o XHTML poderá realmente não ser válido, dado que nenhum elemento contido em 4Q99html.xml poderá fornecer tal garantia. Se tal garantia for requerida, o valor do atributo processContents deverá ser definido ou ajustado como sendo strict (valor estabelecido por defeito do atributo). Neste caso, um processador XML é obrigado a obter o esquema associado ao espaço-nominal requerido, e a validar o XHTML que aparece contido no elemento htmlExample.

Num outro exemplo, nós definimos um tipo text, o qual é similar ao tipo de texto definido na Livraria de Introdução dos tipos do Esquema XML (ver também Livrarias referentes aos Tipos (§5.4.1)), e é apropriado para o texto internacionalizado apto à leitura humana. O tipo [text] permite-nos uma mistura não limitada do conteúdo dos caractéres e elementos a partir de qualquer espaço-nominal, como por exemplo as anotações Ruby, lado a lado com um atributo opcional designado de xml:lang. O valor lax pertencente ao atributo processContents, dá instruções ao processador XML para validar o conteúdo do elemento numa base do tipo "can-do": ele validará elementos e atributos para os quais ele consiga obter informações do esquema, mas não sinalizará erros para os quais ele não consiga obter nenhuma informação referente ao esquema.

Os espaços-nominais poderão ser usados para permitir ou impedir que o conteúdo dos elementos dependa de variadas formas do valor do atributo namespace, como nos é exibido no Quadro 4:

Quadro 4. Atributo do Espaço-nominal em [Any]
Valor do Atributo do Espaço-nominal Conteúdo dos Elementos que é permitido
##any Qualquer XML que seja bem construído, a partir de qualquer espaço-nominal (por defeito)
##local Qualquer XML bem construído mas que não esteja qualificado ou seja, que não seja declarado para estar no espaço-nominal
##other Qualquer elemento XML bem formado que pertença a um outro espaço-nominal que não o espaço-nominal de destino do tipo a ser definido (elementos não qualificado não são aqui permitidos)
"http://www.w3.org/1999/xhtml ##targetNamespace" Qualquer XML bem formado, pertencente a qualquer espaço-nominal contido na lista (separada por espaços em branco); ##targetNamespace é a forma abreviada para o espaço-nominal de destino do tipo a ser definido

A adicionar ao elemento any o qual permite que o conteúdo dos elementos esteja de acordo com os espaços-nominais, existe um atributo a ele correspondente, designado de anyAttribute, o qual permite que os atributos possam aparecer contidos nos elementos. Por exemplo, nós permitir que qualquer atributo XHTML apareça como parte do elemento htmlExample, somando anyAttribute à sua declaração:

Esta declaração permite que um atributo XHTML, digamos por exemplo href, apareça contido no elemento htmlExample. Por exemplo:

O atributo namespace contido num elemento anyAttribute poderá ser ajustado ou definido por qualquer um dos valores listados no Quadro 4 para o elemento any, e o atributo anyAttribute poderá ser especificado com um atributo processContents. Contrastando com o elemento any, o atributo anyAttribute não poderá restringir o número de atributos que podem aparecer num elemento.

previous sub-section next sub-section5.6 Localização do Esquema [schemaLocation]

O Esquema XML Schema serve-se dos atributos schemaLocation e xsi:schemaLocation em três circunstâncias:

1. Num documento de instância, o atributo xsi:schemaLocation fornece sugestões do autor a um processador, tendo em conta a localização dos documentos do esquema. O autor garante que esses documentos do esquema são relevantes na verificação da validade do conteúdo do documento, em cada um dos espaços-nominais. Por exemplo, nós podemos indicar a localização do esquema do Relatório ao processador do Relatório Trimestral:

O valor do atributo schemaLocation consiste num ou mais pares de referências URI, separados por um espaço em branco. O primeiro membro de cada par é um espaço-nominal e o segundo membro consiste numa descrição que define a localidade onde se poderá encontrar um documento do esquema, apropriado para esse espaço-nominal. A presença dessas descrições não requer que o processador tenha de obter e usar os referidos documentos do esquema, estando ele livre para o uso de outros esquemas obtidos através de um dos meios apropriados, ou até para dispensar o seu uso.

Não é aqui necessário que o esquema contenha um espaço-nominal (ver Espaços-nominais de Destino não Declarados (§3.4)), existido portanto o atributo noNamespaceSchemaLocation, o qual é utilizado com o fim de fornecer a descrição da localização dos documentos do esquema que não contenham espaços-nominais de destino.

2. No esquema, o elemento include contém o atributo schemaLocation que é requerido e ainda uma referência URI, a qual terá de identificar o documento do esquema. O objectivo será a composição de um esquema final efectivo, fundindo as declarações e definições dos esquemas [inclusivo] e [incluído]. Por exemplo, no Capítulo Conceitos Avançados II: A Nota de Encomenda Internacional (§4), as definições dos tipos Address, USAddress, UKAddresse USState (conjuntamente com os seus atributos e declarações dos elementos locais) pertencentes a address.xsd, foram adicionadas às declarações dos elementos de purchaseOrder e comment, e ainda às definições dos tipos de PurchaseOrderType, Items e SKU (conjuntamente com os seus atributos e declarações dos elementos locais) pertencentes a ipo.xsd to create a single schema.

3. Também no esquema, o elemento import possui os atributos opcionais namespace e schemaLocation. Se ele estiver presente, o atributo schemaLocation é interpretado de uma forma que se assemelha à interpretação de xsi:schemaLocation no ponto (1). Mais especificamente, ele fornece a indicação dada pelo autor ao processador, tendo em conta a localização do documento do esquema que o autor garante proporcionar os componentes requeridos para o espaço-nominal que é identificado pelo atributo namespace. De forma a se poderem importar componentes que que não estejam contidos em nenhum espaço-nominal de destino, o elemento import é utilizado sem o atributo namespace attribute (e ainda com ou sem o atributo schemaLocation As referências feitas aos componentes que sejam importados desta forma não são qualificadas.

Note-se que o atributo schemaLocation é apenas uma indicação, pelo que em alguns processadores e em algumas aplicações haverão razões suficientes para não se fazer uso dele. Por exemplo, um editor XHTML poderá conter um esquema XHTML integrado (built-in).

previous sub-section 5.7 Concordância

Um documento de instância pode ser processado contra um esquema, a fim de se verificar se as regras especificadas no esquema são cumpridas na instância. Tipicamente, tal processo baseia-se em duas acções: (1) verifica a concordância para com as regras, num processo intitulado de validação do esquema, e (2) adiciona informação suplementar, a qual não está logo de imediato presente na instância, como por exemplo os valores dos tipos e os valores atribuídos por defeito, intitulados de contribuições informativas.

O autor de um documento de instância, com por exemplo uma nota de encomenda particular, poderá especificar, ainda na própria instância, que ela esteja em concordância com as regras de um esquema em particular. O autor poderá fazê-lo usando o atributo schemaLocation, o qual foi já mais acima discutido. Contudo, não atendendo ao facto se o atributo schemaLocation está ou não presente, uma aplicação é livre de processar o documento contra qualquer esquema. Por exemplo, a aplicação de um pedido poderá ter como política, o facto de utilizar um determinado esquema da nota de encomenda, não atendendo a nenhum dos valores do atributo schemaLocation.

A verificação dessa concordância poderá ser realizada em vários passos, verificando-se primeiro se o elemento da raíz da instância do documento possui os conteúdos certos, e depois a conformidade de cada sub-elemento segundo a sua descrição no esquema e por aí adiante, até que o documento tenha sido verificado por completo. Os processadores são aqui requeridos para confirmar o tipo de de comprovações que levaram a cabo.

Para verificar a conformidade de um elemento, o processador localiza primeiramente a declaração do elemento contidos no esquema, verificando depois se o atributo targetNamespace contido no esquema corresponde ao actual espaço-nominal URI do elemento. Alternativamente, ele poderá determinar que o esquema não contém o atributo , targetNamespace e que o elemento da instância não está qualificado no que se refere ao seu espaço-nominal.

Supondo que o espaço-nominal preenche os requesitos, o processador examinará então o tipo do elemento, quer segundo o definido pela declaração contida no esquema, ou pelo atributo xsi:type contido na instância. Se se verificar este último caso, o tipo da instância deverá consistir numa substituição permitida para o tipo indicado no esquema; tudo aquilo que é permitido é controlado pelo atributo block, contido na declaração do elemento. Ao mesmo tempo, os valores atribuídos por defeito e outras contribuições informativas serão devidamente aplicados.

De seguida, o processador verifica os atributos imediatos e os conteúdos do elemento, comparando-os aos atibutos e conteúdos permitidos pelo tipo do elemento. Por exemplo, considerando o elemento shipTo, tal como o que poderá ser encontrado na Nota de Encomenda (§2.1), o processador verifica quais as condições permitidas para Address, uma vez que shipTo é, nomeadamente, o tipo do elemento.

Se o elemento possuir um tipo simples, o processador verificará se o elemento não contém atributos ou elementos nele contidos, e que o conteúdo dos seus caractéres preenche as regras definidas para os tipos simples. Tal facto envolve por vezes a verificação da sequência dos caractéres, face às expressões regulares ou enumerações, e ainda se a mesma sequência dos caractéres representa o valor permitido numa determinada escala de valores.

Se o elemento possuir um tipo complexo, então o processador verificará se todos os atributos requeridos se encontram presentes e se os seus valores estão em conformidade com os requesitos dos seus tipos simples. Ele verificará ainda se todos os sub-elementos requeridos se encontram presentes e se a sequência dos sub-elementos (e de qualquer texto misto) corresponde e preenche os requesitos necessários do modelo de conteúdo que foi declarado para o tipo complexo. Olhando aos sub-elementos, os esquemas podem requerir uma combinação nominal exacta, permitir que os elementos sejam substituídos por elementos equivalentes ou substituidos por qualquer elemento, facto que é permitido através do uso da partícula "any".

A menos que o esquema indique o contrário ( como o poderá fazer no caso das partículas "any", a verificação da concordância prosseguirá então a um nível mais avançado, inspeccionando os elemento um por um, repetindo o todo processo acima descrito.

A Agradecimentos

Muitas foram as pessoas que contribuíram com as suas ideias, materiais e feedback, os quais melhoraram este documento. O editor deste documento gostaria de agradecer especialmente as contribuições de David Beech, Paul Biron, Don Box, Allen Brown, David Cleary, Dan Connolly, Roger Costello, Martin Dürst, Martin Gudgin, Dave Hollander, Joe Kesselman, John McCarthy, Andrew Layman, Eve Maler, Ashok Malhotra, Noah Mendelsohn, Michael Sperberg-McQueen, Henry Thompson, Misha Wolf, e Priscilla Walmsley, pelo facto de eles terem validado os exemplos.

Pela altura em que a primeira edição desta especificação foi publicada, os membros pertencentes ao Grupo de Trabalho do Esquema XML foram nomeadamente:

  • Jim Barnette, Defense Information Systems Agency (DISA)
  • Paul V. Biron, Health Level Seven
  • Don Box, DevelopMentor
  • Allen Brown, Microsoft
  • Lee Buck, TIBCO Extensibility
  • Charles E. Campbell, Informix
  • Wayne Carr, Intel
  • Peter Chen, Bootstrap Alliance e LSU
  • David Cleary, Progress Software
  • Dan Connolly, W3C (contacto da equipa)
  • Ugo Corda, Xerox
  • Roger L. Costello, MITRE
  • Haavard Danielson, Progress Software
  • Josef Dietl, Mozquito Technologies
  • David Ezell, Hewlett-Packard Company
  • Alexander Falk, Altova GmbH
  • David Fallside, IBM
  • Dan Fox, Defense Logistics Information Service (DLIS)
  • Matthew Fuchs, Commerce One
  • Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd)
  • Paul Grosso, Arbortext, Inc
  • Martin Gudgin, DevelopMentor
  • Dave Hollander, Contivo, Inc (Adjunto)
  • Mary Holstege, Perito Convidado
  • Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd)
  • Rick Jelliffe, Academia Sinica
  • Simon Johnston, Rational Software
  • Bob Lojek, Mozquito Technologies
  • Ashok Malhotra, Microsoft
  • Lisa Martin, IBM
  • Noah Mendelsohn, Lotus Development Corporation
  • Adrian Michel, Commerce One
  • Alex Milowski, Perito Convidado
  • Don Mullen, TIBCO Extensibility
  • Dave Peterson, Graphic Communications Association
  • Jonathan Robie, Software AG
  • Eric Sedlar, Oracle Corp.
  • C. M. Sperberg-McQueen, W3C (Adjunto)
  • Bob Streich, Calico Commerce
  • William K. Stumbo, Xerox
  • Henry S. Thompson, University of Edinburgh
  • Mark Tucker, Health Level Seven
  • Asir S. Vedamuthu, webMethods, Inc
  • Priscilla Walmsley, XMLSolutions
  • Norm Walsh, Sun Microsystems
  • Aki Yoshida, SAP AG
  • Kongyi Zhou, Oracle Corp.

O Grupo de Trabalho do Esquema XML beneficiou da participação e da contribuição de um número de pessoas, as quais não fazem actualmente parte do referido Grupo, incluindo as já acima mencionadas. As afiliações que foram dadas correspondem à data do seu trabalho conjunto com a WG.

  • Paula Angerstein, Vignette Corporation
  • David Beech, Oracle Corp.
  • Gabe Beged-Dov, Rogue Wave Software
  • Greg Bumgardner, Rogue Wave Software
  • Dean Burson, Lotus Development Corporation
  • Mike Cokus, MITRE
  • Andrew Eisenberg, Progress Software
  • Rob Ellman, Calico Commerce
  • George Feinberg, Object Design
  • Charles Frankston, Microsoft
  • Ernesto Guerrieri, Inso
  • Michael Hyman, Microsoft
  • Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd)
  • Dianne Kennedy, Graphic Communications Association
  • Janet Koenig, Sun Microsystems
  • Setrag Khoshafian, Technology Deployment International (TDI)
  • Ara Kullukian, Technology Deployment International (TDI)
  • Andrew Layman, Microsoft
  • Dmitry Lenkov, Hewlett-Packard Company
  • John McCarthy, Lawrence Berkeley National Laboratory
  • Murata Makoto, Xerox
  • Eve Maler, Sun Microsystems
  • Murray Maloney, Muzmo Communication, representando a Firma Commerce One
  • Chris Olds, Wall Data
  • Frank Olken, Lawrence Berkeley National Laboratory
  • Shriram Revankar, Xerox
  • Mark Reinhold, Sun Microsystems
  • John C. Schneider, MITRE
  • Lew Shannon, NCR
  • William Shea, Merrill Lynch
  • Ralph Swick, W3C
  • Tony Stewart, Rivcom
  • Matt Timmermans, Microstar
  • Jim Trezzo, Oracle Corp.
  • Steph Tryphonas, Microstar

As listas que foram acima fornecidas correspondem à primeira edição. Pela altura em que o trabalho nesta segunda edição foi terminado, o Grupo de Trabalho foi formado por:

  • Leonid Arbouzov, Sun Microsystems
  • Jim Barnette, Defense Information Systems Agency (DISA)
  • Paul V. Biron, Health Level Seven
  • Allen Brown, Microsoft
  • Charles E. Campbell, Perito convidado
  • Peter Chen, Perito convidado
  • Tony Cincotta, NIST
  • David Ezell, National Association of Convenience Stores
  • Matthew Fuchs, Perito convidado
  • Sandy Gao, IBM
  • Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd)
  • Xan Gregg, Perito convidado
  • Mary Holstege, Mark Logic
  • Mario Jeckle, DaimlerChrysler
  • Marcel Jemio, Data Interchange Standards Association
  • Kohsuke Kawaguchi, Sun Microsystems
  • Ashok Malhotra, Perito convidado
  • Lisa Martin, IBM
  • Jim Melton, Oracle Corp
  • Noah Mendelsohn, IBM
  • Dave Peterson, Perito convidado
  • Anli Shundi, TIBCO Extensibility
  • C. M. Sperberg-McQueen, W3C (Adjunto)
  • Hoylen Sue, Distributed Systems Technology Centre (DSTC Pty Ltd)
  • Henry S. Thompson, University of Edinburgh
  • Asir S. Vedamuthu, webMethods, Inc
  • Priscilla Walmsley, Perito convidado
  • Kongyi Zhou, Oracle Corp.

Gostaríamos ainda de salientar, com alguma tristeza, a morte acidental de Mario Jeckle, pouco depois do trabalho neste documento ter sido terminado. A adicionar aos nomes que foram acima mencionados, foram várias as pessoas que ajudaram o Grupo de Trabalho durante o desenvolvimento desta segunda edição:

  • Oriol Carbo, University of Edinburgh
  • Tyng-Ruey Chuang, Academia Sinica
  • Joey Coyle, Health Level 7
  • Tim Ewald, DevelopMentor
  • Nelson Hung, Corel
  • Melanie Kudela, Uniform Code Council
  • Matthew MacKenzie, XML Global
  • Cliff Schmidt, Microsoft
  • John Stanton, Defense Information Systems Agency
  • John Tebbutt, NIST
  • Ross Thompson, Contivo
  • Scott Vorthmann, TIBCO Extensibility

B Os Tipos Simples e as suas Propiedades (facets)

Os valores legais para cada um dos tipos poderá ser limitado através da aplicação de uma ou mais propriedades (facets). Os Quadros B1.a e B1.b listam todos os tipos simples integrados (built-ins) do Esquema XML, bem como as propriedades aplicáveis a cada um dos tipos. Os nomes dos tipos simples e das suas características estão hiperligados às respectivas descrições em Esquema XML, Parte 2: Tipos de dados.

Quadro B1.a Tipos Simples & Propriedades Aplicáveis
Tipos Simples Propriedades
length
[longitude]
minLength maxLength pattern enumeration (enumeração) whiteSpace
string y y y y y y
normalizedString(string normalizada) y y y y y y
token y y y y y ver (1)
base-binária-64 y y y y y ver (1)
hexBinary y y y y y ver (1)
integer y y ver (1)
positiveInteger y y ver (1)
negativeInteger y y ver (1)
nonNegativeInteger y y ver (1)
nonPositiveInteger y y ver (1)
long y y ver (1)
unsignedLong y y ver (1)
int y y ver (1)
unsignedInt y y ver (1)
short y y ver (1)
unsignedShort y y ver (1)
byte y y ver (1)
unsignedByte y y ver (1)
decimal y y ver (1)
float y y ver (1)
double y y ver (1)
boolean y ver (1)
duration (duração) y y ver (1)
dateTime (dataHora) y y ver (1)
date (data) y y ver (1)
time (hora) y y ver (1)
gYear y y ver (1)
gYearMonth y y ver (1)
gMonth y y ver (1)
gMonthDay y y ver (1)
gDay y y ver (1)
Name (Nome) y y y y y ver (1)
QName y y y y y ver (1)
NCName y y y y y ver (1)
anyURI(qualquer URI) y y y y y ver (1)
language (linguagem) y y y y y ver (1)
ID y y y y y ver (1)
IDREF y y y y y ver (1)
IDREFS y y y y y ver (1)
ENTIDADE y y y y y ver (1)
ENTIDADES y y y y y ver (1)
ANOTAÇÕES y y y y y ver (1)
NMTOKEN y y y y y ver (1)
NMTOKENS y y y y y ver (1)
Nota: (1) Embora o "facet" do whiteSpace seja aplicada a este tipo, o único valor que poderá ser especificado é o collapse.

As propriedades listadas no Quadro B1.b só se aplica aos tipos simples que sejam ordenados. Nem todos os tipos simples estão ordenados, de maneira que o Quadro B1.b não contém todos os tipos simples listados.

Quadro B1.b. Tipos Simples & Propriedades Aplicáveis
Tipos Simples Propriedades
max
Inclusive
max
Exclusive
min
Inclusive
min
Exclusive
total
Digits
fraction
Digits
integer y y y y y ver (1)
positiveInteger y y y y y ver (1)
negativeInteger y y y y y ver (1)
nonNegativeInteger y y y y y ver (1)
nonPositiveInteger y y y y y ver (1)
long y y y y y ver (1)
unsignedLong y y y y y ver (1)
int y y y y y ver (1)
unsignedInt y y y y y ver (1)
short y y y y y ver (1)
unsignedShort y y y y y ver (1)
byte y y y y y ver (1)
unsignedByte y y y y y ver (1)
decimal y y y y y y
float y y y y
double y y y y
duration y y y y
dateTime y y y y
date y y y y
time y y y y
gYear y y y y
gYearMonth y y y y
gMonth y y y y
gMonthDay y y y y
gDay y y y y
Nota: (1) Embora a propriedade fractionDigits seja aplicável a este tipo, o único valor que poderá ser especificado é o zero.

C Usando as Entidades

O XML 1.0 fornece-nos vários tipos de entidades , as quais são em realidade fragmentos do conteúdo aos quais lhes foram dado um nome que poderá ser usado na construção dos DTD's (entidades dos parâmetros) e dos documentos de instância. No Capítulo Construindo os Modelos do Conteúdo (§2.7), nós reparámos na forma como os grupos nomeados mimetizam as entidades dos parâmetros. Nesta secção, nós exibiremos a forma como as entidades podem ser declaradas num documento de instância, bem como os equivalentes funcionais das entidades poderão ser declarados nos esquemas.

Suponhamos que nós queremos declarar e usar uma entidade num documento de instância e que esse documento também é restringido por um esquema. Por exemplo:

Aqui, nós declaramos uma entidade denominada eacute parte de um conjunto interno (DTD), e referenciamos essa entidade no conteúdo do elemento city. Note que quando este documento de instância é processado, a entidade será resolvida antes da validação do esquema tomar lugar. Por outras palavras, o processador do esquema determinará a validade do elemento city, usando Montréal como sendo o valor do elemento.

Nós poderemos obter um efeito similar mas não idêntico, declarando um elemento num esquema e definindo o conteúdo do elemento da forma mais apropriada:

Exemplo
<xsd:element name="eacute" type="xsd:token" fixed="&#xE9;"/>

Este elemento poderá ser utilizado num documento de instância:

Neste caso, o processador do esquema processará dois elementos, o elemento city e o elemento eacute, para cujos os conteúdos o processador fornecerá o caractére isolado é. Note que os elementos extras complicam as combinações das string; as duas formas do nome "Montréal" que foram dadas nos dois exemplos acima não se irão influenciar, usando uma técnica de comparação de strings normal.

D Expressões Regulares

A propriedade pattern, contida no Esquema XML, usa uma linguagem de expressão regular que suporta Unicode. Ela é descrita na sua íntegra, no Documento Esquema XML, Parte 2. A linguagem é similar à linguagem de expressão regular usada na Linguagem de Programação Perl, se bem que as expressões sejam aqui classificadas de acordo com a totalidade das suas representações lexicais, em vez de serem focalizadas de acordo com um lexico de utente, tais como linha e parágrafo. Por esta razão, a linguagem da expressão não contém os metacaractéres ^ e $, embora ^ seja usado para expressar uma excepção, como por exemplo [^0-9]x.

Quadro D1. Exemplos de Expressões Regulares
Expressão Valores coincidentes
Capítulo \d Capítulo 0, Capítulo 1, Capítulo 2 ....
Capítulo\s\d Capítulo seguido de um único espaço em branco (espaço, tabulador, mudança de linha, etc), seguido de um único dígito
Capítulo\s\w Capítulo seguido de um único espaço em branco (espaço, tabulador, mudança de linha, etc), seguido de um caractére alfabético (XML 1.0 Letra ou Dígito)
Española Española
\p{Lu qualquer letra maíuscula, o valor de \p{} (exemplo: "Lu") é definido por Unicode
\p{IsGreek qualquer caractére do alfabeto Grego, a construção ‘ Is ' pode ser aplicada a qualquer bloco nominativo (exemplo: "Grego"), como o definido em Unicode
\P{IsGreek qualquer caractére não pertencente ao alfabeto Grego, a construção ‘ Is ' pode ser aplicada a qualquer bloco nominativo (exemplo: "Grego"), como o definido através de Unicode
a*x x, ax, aax, aaax ....
a?x ax, x
a+x ax, aax, aaax ....
(a|b)+x ax, bx, aax, abx, bax, bbx, aaax, aabx, abax, abbx, baax, babx, bbax, bbbx, aaaax ....
[abcde]x ax, bx, cx, dx, ex
[a-e]x ax, bx, cx, dx, ex
[\-ae]x -x, ax, ex
[ae\-]x ax, ex, -x
[^0-9]x qualquer caractére não numerativo, seguido do caractére x
\Dx qualquer caractére não numerativo, seguido do caractére x
.x qualquer caractére seguido do caractére x
.*abc.* 1x2abc, abc1x2, z3456abchooray ....
ab{2}x abbx
ab{2,4}x abbx, abbbx, abbbbx
ab{2,}x abbx, abbbx, abbbbx ....
(ab){2}x ababx

E Index

next sub-sectionE.1 Elementos pertencentes ao Esquema XML

Cada elemento nominativo é seguido de um ou mais Links com exemplos (identificados pelo número da secção) contidos nos Princípios Básicos, mais um Link para a descrição XML formal, tanto na especificação das partes das Extruturas como ainda nas dos Tipos dos Dados do Esquema XML .

all: [ (§2.7)] [Estruturas]
annotation: [ (§2.6)] [Estruturas]
any: [ (§5.5)] [Estruturas]
anyAttribute: [ (§5.5)] [Estruturas]
appinfo: [ (§2.6)] [Estruturas]
attribute: [ (§2.2)] [Estruturas]
attributeGroup: [ (§2.8)] [Estruturas]
choice: [ (§2.7)] [Estruturas]
complexContent: [ (§2.5.3)] [Estruturas]
complexType: [ (§2.2)] [Estruturas]
documentation: [ (§2.6)] [Estruturas]
element: [ (§2.2)] [Estruturas]
enumeration: [ (§2.3)] [Datatypes]
extension: [ (§2.5.1)] [Estruturas], [ (§4.2)] [Estruturas]
field: [ (§5.1)] [Estruturas]
group: [ (§2.7)] [Estruturas]
import: [ (§5.4)] [Estruturas]
include: [ (§4.1)] [Estruturas]
key: [ (§5.2)] [Estruturas]
keyref: [ (§5.2)] [Estruturas]
length: [ (§2.3.1)] [Datatypes]
list: [ (§2.3.1)] [Datatypes]
maxInclusive: [ (§2.3)] [Datatypes]
maxLength: [ (§2.3.1)] [Datatypes]
minInclusive: [ (§2.3)] [Datatypes]
minLength: [ (§2.3.1)] [Datatypes]
pattern: [ (§2.3)] [Datatypes]
redefine: [ (§4.5)] [Estruturas]
restriction: [ (§2.3)] [Datatypes], [ (§4.4)] [Estruturas]
schema: [ (§2.1)] [Estruturas]
selector: [ (§5.1)] [Estruturas]
sequence: [ (§2.7)] [Estruturas]
simpleContent: [ (§2.5.1)] [Estruturas]
simpleType: [ (§2.3)] [Datatypes]
union: [ (§2.3.2)] [Datatypes]
unique: [ (§5.1)] [Estruturas]

previous sub-section E.2 Atributos do Esquema XML

Cada nome de atributo é seguido de um ou mais pares de referências. Cada par de referências consiste numa hiperligação a um exemplo contido nos Princípios Básicos, mais um Link para a descrição XML formal, tanto na especificação das partes das Extruturas como ainda nas dos Tipos dos Dados do Esquema XML .

abstract: declaração do elemento [Estruturas]
abstract: definição do tipo complexo [Estruturas]
attributeFormDefault: definição do esquema [Estruturas]
base: definição do tipo simples [Datatypes]
base: definição do tipo complexo [Estruturas]
block: definição do tipo complexo [Estruturas]
blockDefault: definição do esquema [Estruturas]
default: declaração do atributo [Estruturas]
default: declaração do elemento [Estruturas]
elementFormDefault: definição do esquema [Estruturas]
final: definição do tipo complexo [Estruturas]
finalDefault: definição do esquema [Estruturas]
fixed: declaração do atributo [Estruturas]
fixed: declaração do elemento [Estruturas]
fixed: definição do tipo simples [Datatypes]
form: declaração do atributo [Estruturas]
form: declaração do elemento [Estruturas]
itemType: definição do tipo de lista [Datatypes]
memberTypes: definição do tipo [união] [Datatypes]
maxOccurs: declaração do elemento [Estruturas]
minOccurs: declaração do elemento [Estruturas]
mixed: definição do tipo complexo [Estruturas]
name: declaração do elemento [Estruturas]
name: declaração do atributo [Estruturas]
name: definição do tipo complexo [Estruturas]
name: definição do tipo simples [Datatypes]
namespace: element wildcard [Estruturas]
namespace: import specification [Estruturas]
xsi:noNamespaceSchemaLocation: elemento de instância [Estruturas]
xsi:nil: elemento de instância [Estruturas]
nillable: declaração do elemento [Estruturas]
processContents: element wildcard [Estruturas]
processContents: attribute wildcard [Estruturas]
ref: declaração do elemento [Estruturas]
schemaLocation: include specification [Estruturas]
schemaLocation: redefine specification [Estruturas]
schemaLocation: import specification [Estruturas]
xsi:schemaLocation: elemento de instância [Estruturas]
substitutionGroup: declaração do elemento [Estruturas]
targetNamespace: definição do esquema [Estruturas]
type: declaração do elemento [Estruturas]
type: declaração do atributo [Estruturas]
xsi:type: elemento de instância [Estruturas]
use: declaração do atributo [Estruturas]
xpath: definição das restrições de identidade [Estruturas]

Os tipos simples contidos no Esquema XML são descritos no Quadro 2.