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).

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.

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:

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

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.

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:

<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].

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.

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.

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.

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.

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:

<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:

<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:

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

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".

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.

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.

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

<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.

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.

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

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:

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:

<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:

<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.

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.

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.

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:

<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]:

<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.

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.

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.

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.

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:

<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:

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.

<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.).

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.

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.

À 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:

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:

<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.

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:

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.

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.

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).

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:

 ....
 <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.

....
<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.

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:

<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:

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

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

<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.

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:

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.

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.

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:

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.

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.

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:

<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:

<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:

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.

À 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:

<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.

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:

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:

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.

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).

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.

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:

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

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.