Esta é uma tradução da recomendação XML Schema Part 0 Primer Second Edition do W3C, cuja versão original poderá ser encontrada em:
http://www.w3.org/TR/xmlschema-0/
Alerta-se aqui para o facto desta tradução poder conter erros, próprios e inerentes a cada tradução deste tipo. Certo tipo de conceitos são difíceis de traduzir para o Português, ou deveriam ainda ser contemplados com uma explicação mais plausível. Em todo o caso, tentou-se aqui uma aproximação exacta ao contexto original.
Por favor, consulte a errata deste documento, a qual poderá conter eventuais correcções normativas.
Este documento também está disponível nos seguintes formatos
(não-normativos): XML
e XHTML,
com uma visível mudança do markup. Veja também as respectivas
Copyright © 2004 W3C® (MIT, ERCIM, Keio). Todos os direitos são reservados! Aplicam-se aqui as disposições legais do W3C relativas às responsabilidades, às marcas registradas e ao uso de documentos.
Esquema XML, Parte 0: Princípios Básicos é um documento não-normativo, com o qual se pretende fornecer uma descrição de fácil leitura das facilidades relacionadas com o Esquema XML, e é orientado no sentido de uma rápida compreensão da forma como se criam as linguagens dos referidos esquemas. Esquema XML, Parte 1: Estruturas e Esquema XML, Parte 2: Tipos de dados fornecem a descrição normativa da linguagem referente ao Esquema XML por completo. Este documento descreve as características da liguagem através de numerosos exemplos, os quais são ainda complementados pelas extensivas referências aos textos normativos.
Esta secção descreve o estatuto do documento pela altura da sua publicação. Ele poderá vir a ser ultrapassado e substituído por outros documentos. A lista com as actuais publicações do W3C e com as mais recentes revisões deste relatório técnico poderão ser encontradas no Índex dos relatórios técnicos do W3C em http://www.w3.org/TR/.
Esta é uma Recomendação do W3C, a primeira parte da 2a. Edição do Esquema XML. Este documento foi revisto pelos Membros do W3C, bem como por outras partes nele interessadas, tendo sido endossado pelo Director na qualidade de Recomendação do W3C. Ele provém de fontes fidedignas e poderá ser utilizado como material de referência. O W3C tem por objectivos, ao elaborar esta Recomendação, a chamada de atenção para esta especificação e ainda promover e divulgar a sua distribuição. Essa acção realça a funcionabilidade e a inter-operacionabilidade da Web.
Este documento foi produzido pelo Grupo de Trabalho do W3C responsável pelo Esquema XML como parte da Actividade XML do W3C. Os objectivos pretendidos no uso da linguagem do Esquema XML são discutidos no documento Requesitos do Esquema XML. Os autores deste documento são membros pertencentes ao Grupo de Trabalho do W3C responsável pelo Esquema XML. As diferentes partes desta especificação foram elaboradas por vários editores.
Este documento foi produzido de acordo com a Práticas Actuais das Patentes, de 24 de Janeiro de 2002 (CPP) segundo a emenda estabelecida pelo Procedimento de Transição da Política das Patentes do W3C. O Grupo de Trabalho mantém uma lista pública com as divulgações das patentes, a qual é relevante para este documento; essa página inclui ainda instruções que explicitam a divulgação das patentes. Um indivíduo que possua o actual conhecimento de uma patente, a qual ele acredite conter as indicações essenciais respeitantes a estas especificações, deverá divulgar essa informação, de acordo com a secção 6 da Política das Patentes do W3C.
A versão desta especificação em Inglês é a única versão normativa. As informações referentes às traduções deste documento estão disponíveis em http://www.w3.org/2001/05/xmlschema-translations.
Esta 2a. edição não é em realidade nenhuma nova versão, ela incorpora apenas as alterações ditadas pelas correcções dos erros encontrados na 1a. edição segundo acordado pelo Grupo de Trabalho responsável pelo Esquema XML, como sendo o mais conveniente para os demais leitores. Uma lista em separado, contendo todas essas correcções, poderá ser encontrada em http://www.w3.org/2001/05/xmlschema-errata.
A lista da errata para esta 2ª. Edição está disponível em http://www.w3.org/2004/03/xmlschema-errata.
Por favor, relate-nos qualquer erro encontrado neste documento, através do endereço electrónico [email protected] (arquivo).
1 Introdução
2
Conceitos
Básicos: A Ordem de Aquisição
2.1 Esquema
da Ordem de Aquisição
2.2 Definições
dos Tipos Complexos, Declarações dos Elementos e dos
Atributos
2.3 Tipos
Simples
2.4 Definições
do Tipo Anónimo
2.5 Índice
dos Elementos
2.6 Anotações
2.7
Modelos
da Construção dos Conteúdos
2.8 Grupos de
Atributos
2.9 Valores
Nil
3 Conceitos
Avançados I: Espaços-nominais, Esquemas &
Qualificações
3.1 Espaços-nominais
Alvo & Locais não qualificados
3.2 Locais
Qualificados
3.3 Declarações
Globais e Locais
3.4 Espaços-nominais
Alvo não declarados
4 Conceitos
Avançados II: Ordem de Aquisição
Internacional
4.1 Um
Esquema em Múltiplos Documentos>
4.2 Derivando
Tipos por Extensão
4.3 Utilizando
os Tipos Derivados nos Documentos de
Instância
4.4 Derivando
os Tipos Complexos por Restrição
4.5 Redefinindo
os Tipos e os Grupos
4.6 Grupos
de Substituição
4.7 Elementose
Tipos Abstractos
4.8 Controlando
o Uso e a Criação dos Tipos Derivados
5 Conceitos
Avançados III: O Relatório Trimestral
5.1 Especificando
as Singularidades
5.2 Definindo
as Teclas-chave e as suas Referências
5.3 Restrições
do Esquema XML (x) Atributos ID do XML 1.0
5.4
Importando
Tipos
5.5 Qualquer
Elemento, Qualquer Atributo
5.6 Localização
do Esquema
5.7 Conformidades
A Agradecimentos
B
Os
Tipos Simples e as suas Facetas
C Utilizando
as Entidades
D Expressões
Regulares
E Índex
E.1
Elementos
do Esquema XML
E.2 Atributos
do Esquema XML
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.
A finalidade de um esquema é a de definir uma classe de documentos XML, de forma que o termo “documento de instância” é frequentemente utilizado para descrever um documento XML que esteja em conformidade com um esquema em particular. De facto, nem as instâncias nem os esquemas necessitam de existir na qualidade de documentos per se -- eles podem existir como fluxos de bits, enviados entre as aplicações, como campos de registro numa base de dados, ou como colecções dos “Itens de Informação” dos Infosets XML – mas, a fim de simplificar estes fundamentos, nós escolhemos referir as instâncias e os esquemas como se tratassem eles de documentos ou de ficheiros.
Comecemos pois, considerando um documento contido num ficheiro, chamado
po.xml
.
Ele descreve uma nota de encomenda, emitida para a encomenda de produtos
caseiros e sua respectiva facturação:
A nota de encomenda consiste num elemento principal, a Nota de
Encomenda
, e nos sub-elementos shipTo(enviar para)
,
billTo (cobrar a)
, comment (comentário)
, e
itens
. Estes sub-elementos (à excepção do comentário
)
contêm por sua vez outros sub-elements, e por aí adiante, sendo de considerar
ainda que sub-elementos como USPrice (preço praticado nos USA)
,
contêm um número em vez de conter outros sub-elementos. Elementos que contenham
outros sub-elementos ou transportem determinado tipo de atributos são
considerados como possuindo um tipo complexo, ao passo que os elementos que
contenham números (ou ainda strings, datas, etc.) e não outros sub-elementos
quaisquer, são considerados como possuindo um tipo simples. Alguns elementos têm
atributos; os atributos têm sempre um tipo simples.
Os tipos complexos nos documentos de instância, bem como alguns dos tipos simples, são definidos no esquema destinado às notas de encomenda. Os restantes tipos simples são definidos como parte do reportório dos tipos simples pré-definidos do Esquema XML.
Antes de continuarmos aqui a examinar o esquema correspondente à nota de encomenda, nós iremos aqui antes mencionar resumidamente a relação entre o documentos de instância e o esquema da nota de encomenda. Como você próprio poderá concluir, através da análise do documento de instância, o esquema da nota de encomenda não é mencionado. Em realidade, não é necessário que um documento de instância faça qualquer tipo de referências ao esquema, e se bem que muitos assim o façam, nós escolhemos manter esta 1ª. secção no seu estado simples e partir do princípio de que qualquer processador do documento de instância pode obter o esquema da nota de encomenda, sem que esta possua qualquer informação adicional do documento de instância. Em secções posteriores, nós iremos explicar os mecanismos de associação dos esquemas e dos documentos de instância.
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.
Quadro 1. Restrições de Ocorrência para os Elementos e Atributos | |||||||
---|---|---|---|---|---|---|---|
|
|
Notas | |||||
(1, 1) -, - | são requeridos, -, - | elemento/atributo deve aparecer uma vez, podendo ter qualquer valor | |||||
(1, 1) 37, - | são requeridos, 37, - | elemento/atributo deve aparecer uma vez, o seu valor deverá ser 37 | |||||
(2, unbounded) 37, - | n/a | o elemento deve aparecer duas ou mais vezes, o seu valor deverá ser 37; em geral, os valores minOccurs e maxOccurs deverão ser números inteeiros positivos, devendo ainda o valor maxOccurs ser [“unbounded” (ilimitado)] | |||||
(0, 1) -, - | opcional, -, - | o elemento/atributo poderá aparecer uma vez e assumir qualquer valor | |||||
(0, 1) 37, - | n/a | o elemento pode aparecer uma vez, mas se ele não aparecer tal não será necessário; se ele não aparecer e estiver vazio, o seu valor é 37; se ele aparecer e não estiver vazio, o seu valor deverá ser 37 | |||||
n/a | opcional, 37, - | o atributo pode aparecer uma vez, se ele aparecer valor deverá ser 37, se não aparecer o seu valor será na mesma 37 | |||||
(0, 1) -, 37 | n/a | o elemento poderá aparecer uma vez; se ele não aparecer tal não será necessário; se ele aparecer e estiver vazio, o seu valor é 37; senão o seu valor deverá ser aquele que foi dado | |||||
n/a | opcional, -, 37 | o atributo poderá aparecer uma vez; se ele não aparecer, o seu valor é 37, senão o seu valor deverá ser aquele que foi atribuído | |||||
(0, 2) -, 37 | n/a | o elemento pode aparecer uma ou duas vezes, ou até nem aparecer; se o elemento não aparecer, tal não será necessáriamente aplicável; se ele aparecer e estiver vazio, o seu valor será 37;senão o seu valor deverá ser aquele que foi dado; em geral, os valores minOccurs and maxOccurs poderão ser ser números inteiros positivos, e o valor maxOccurs também poderá ser "unbounded" | |||||
(0, 0) -, - | probido, -, - | elemento/atributo não necessitam de aparecer indicados | |||||
Note-se que tanto o minOccurs, o maxOccurs, como ainda o use não podem aparecer nas declarações dos elementos e atributos globais. |
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.
Acabámos de descrever como definir os novos tipos complexos (por exemplo:
PurchaseOrderType
), como declarar elementos (por exemplo:
purchaseOrder
) e como declarar atributos (por exemplo:
orderDate
). Essas actividades envolvem geralmente a atribuição de
um novo, de forma que a questão que agora se coloca é a seguinte: O que é que
acontece se atribuírmos o mesmo nome a duas coisas distintas? A resposta a esta
pergunta dependerá das duas coisas em questão, embora o mais certo seja, que
quanto mais similares forem essas duas coisas, maior será a probabilidade de
conflito entre elas.
Eis aqui alguns exemplos para ilustrar o caso referente aos problemas causados pela atribuição de nomes iguais a elementos diferentes. Digamos por exemplo, que esses dois elementos ou objectos se tratam de tipos, definindo nós aqui um tipo complexo chamado USStates e um tipo simples chamado USStates: entre eles dar-se-á automáticamente um conflito. Se os dois objectos forem nomeadamente um tipo e um elemento ou atributo, definindo aqui por exemplo um tipo complexo chamado USAddress e um elemento chamado USAddress, não existirá qualquer tipo de conflito entre eles. Se esses dois objectos pertencerem a dois tipos diferentes (isso significa que eles se tratam de elementos não globais) e se nós definirmos um elemento chamado nome, como parte pertencente ao tipo USAddress, e ainda um segundo elemento chamado nome, como parte pertencente ao tipo Item, então não haverá qualquer conflito. (Tais objectos são por vezes denominados de declarações dos elementos locais.) Por fim, se esses dois objectos forem tipos, se você definir um deles como tipo simples decimal e o Esquema XML definir o outro, não haverá qualquer conflito entre eles. A razão para a aparente contradição verificada neste último exemplo, dá-se ao facto dos dois tipos pertencerem a espaços-nominais (namespaces) diferentes. Nós aprofundaremos o uso dos espaços-nominais no esquema, numa secção posterior.
O esquema da nota de encomenda especifica vários elementos e atributos que
têm tipos simples. Alguns desse tipos simples, como por exemplo string
e decimal
,
são construídos no Esquema XML, ao passo que os outros derivam dessas
construções (built-ins). Por exemplo, o atributo partNum
possui um
tipo denominado de SKU
(Stock Keeping Unit), o qual deriva de
string
.
Ambos os tipos simples aí incorporados, bem como as suas derivações, poderão ser
usados em todas as declarações de elementos e atributos. No Quadro
2 são listados todos os tipos simples incorporados no Esquema XML,
juntamente com exemplos dos diferentes tipos.
Quadro 2. Tipos Simples incorporados no Esquema XML | ||||
---|---|---|---|---|
Tipos Simples | Exemplos (delimitados por vírgulas) | Notas | ||
string | Confirma que isto é eléctrico | |||
normalizedString | Confirma que isto é eléctrico | ver (3) | ||
token | Confirma que isto é eléctrico | ver (4) | ||
base64Binary | GpM7 | |||
hexBinary | 0FB7 | |||
integer | ...-1, 0, 1, ... | ver (2) | ||
positiveInteger | 1, 2, ... | ver (2) | ||
negativeInteger | ... -2, -1 | ver (2) | ||
nonNegativeInteger | 0, 1, 2, ... | ver (2) | ||
nonPositiveInteger | ... -2, -1, 0 | ver (2) | ||
long | -9223372036854775808, ... -1, 0, 1, ... 9223372036854775807 | ver (2) | ||
unsignedLong | 0, 1, ... 18446744073709551615 | ver (2) | ||
int | -2147483648, ... -1, 0, 1, ... 2147483647 | ver (2) | ||
unsignedInt | 0, 1, ...4294967295 | ver (2) | ||
short | -32768, ... -1, 0, 1, ... 32767 | ver (2) | ||
unsignedShort | 0, 1, ... 65535 | ver (2) | ||
byte | -128, ...-1, 0, 1, ... 127 | ver (2) | ||
unsignedByte | 0, 1, ... 255 | ver (2) | ||
decimal | -1.23, 0, 123.4, 1000.00 | ver (2) | ||
float | -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN | equivalente ao “single-precision 32-bit floating point”, NaN significa “not a number” (não é um número), ver (2) | ||
double | -INF, -1E4, -0, 0, 12.78E-2, 12, INF, NaN | equivalente ao “double-precision 64-bit floating point”, ver (2) | ||
boolean | true (verdadeiro), false (falso), 1, 0 | |||
duration | P1Y2M3DT10H30M12.3S | 1 year (ano), 2 months (meses), 3 days (dias), 10 hours (horas), 30 minutes (minutos), e 12.3 seconds (segundos) | ||
dateTime | 1999-05-31T13:20:00.000-05:00 | 31 de Maio de 1999, 13.20 segundo a hora Eastern Standard Time, a qual anda cinco horas para trás, tendo como base de partida a hora UCT (Universal), ver (2) | ||
date | 1999-05-31 | ver (2) | ||
time | 13:20:00.000, 13:20:00.000-05:00 | ver (2) | ||
gYear | 1999 | 1999, ver (2) (5) | ||
gYearMonth | 1999-02 | mês de Fevereiro, não pormenorizando o número referente aos dias, ver (2) (5) | ||
gMonth | --05 | Maio, ver (2) (5) | ||
gMonthDay | --05-31 | cada 31 de Maio, ver (2) (5) | ||
gDay | ---31 | o dia 31 de Maio, ver (2) (5) | ||
Name | shipTo | Tipo de nome em XML 1.0 | ||
QName | po:USAddress | Espaço-nominal Qname em XML | ||
NCName | USAddress | Espaço-nominal NCName em XML, o que significa que é um Qname sem o prefixo nem os dois pontos | ||
anyURI |
|
|||
language | en-GB, en-US, fr | valores válidos para [xml:lang], como o definido em XML 1.0 | ||
ID | atributo do tipo XML 1.0 [ID], ver (1) | |||
IDREF | atributo do tipo XML 1.0 IDREF, ver (1) | |||
IDREFS | atributo do tipo XML 1.0 IDREFS, ver (1) | |||
ENTITY | atributo do tipo XML 1.0 ENTITY, ver (1) | |||
ENTITIES | atributo do tipo XML 1.0 ENTITIES, ver (1) | |||
NOTATION | atributo do tipo XML 1.0 NOTATION, ver (1) | |||
NMTOKEN |
|
atributo do tipo NMTOKEN em XML 1.0, ver (1) | ||
NMTOKENS |
|
atributo do tipo NMTOKENS XML 1.0, o que à letra significa uma lista separada com espaços em branco de NMTOKEN's, ver (1) | ||
Notas: (1) Para manter a compatibilidade entre o Esquema XML e XML 1.0 DTDs, os tipos simples ID, IDREF, IDREFS, ENTITY, ENTITIES, NOTATION, NMTOKEN, NMTOKENS deverão ser apenas usados nos atributos. (2) Um valor deste tipo pode ser representado por mais do que um formato lexical. Por exemplo, 100 e 1.OE2 são ambos formatos oscilantes válidos representando "cem". Foram contudo estabelecidas regras para este tipo, as quais definem um formato lexical canónico, ver Esquema XML, Parte 2. (3) Os caractéres referentes à mudança de linha, ao tabulador e à tecla de retorno num atributo do tipo [normalizedString], são transformados em espaços em branco, antes do processamento do esquema.(4) Como no caso do atributo [normalizedString], os espaços em branco adjacentes são limitados a um único espaço em branco, e os espaços em branco no princípio e no fim são removidos. (5) O prefixo "g" assinala os períodos de tempo no calendário Gregoriano. |
Os tipos simples novos são definidos através da sua derivação a
partir dos tipos simples já existentes (built-in`s e derivadas).Falando de uma
forma mais detalhada, nós poderemos derivar um novo tipo simples através da
restrição de um tipo simples já existente ou, por outras palavras, a escala dos
valores válidos para este novo tipo é constituída por um sub-conjunto da escala
dos valores dos tipos já existentes. Nós utilizamos o elemento simpleType
para definir e nomear o novo tipo simples. Nós utilizamos o elemento restriction
[restrição] para indicar o tipo já existente (básico) e para identificar as
"facetas"(do Inglês: "facets") ou propriedades que restringem a escala de
valores. A lista completa com essas propriedades é fornecida no documento Appendix
B.
Suponhamos que nós queremos criar um novo tipo de inteiros, ao qual
chamamos myInteger
e cuja escala de valores está compreendida entre
10000 e 99999 (inclusive). Nós baseamos a nossa definição no tipo simples
integrado (do Inglês: "built-in") integer
,
cuja escala de valores também inclui´números inteiros maiores do que 10000 e
menores do que 99999. Para definir myInteger
[meuInteiro], nós
limitámos a escala do tipo base integer
,
empregando duas propriedades, nomeadamente minInclusive
e maxInclusive
:
Este exemplo mostra-nos uma combinação especial entre um tipo base e duas
propriedades ("facets"), com o intuito de definir myInteger
, se bem
que depois de se deitar uma vista de olhos à lista dos tipos simples integrados
bem como às suas propriedades (Apêndice
B) se pudessem idealizar ou sugerir outras combinações possíveis.
O esquema da nota de encomenda contém um outro exemplo, mais
elaborado, da definição do tipo simples.Um novo tipo simples, denominado de
SKU
, é derivado (por restrição) do tipo simples string
.
Além disso, nós restringimos os valores de SKU
, utilizando uma
propriedade chamada pattern
,
em conjunção com a expressão regular "\d{3}-[A-Z]{2}
" que se pode
ler como "três digitos seguidos de um hífen seguido de dois caractéres ASCII em
letras maiúsculas":
Esta linguagem de expressões regulares é descrita mais detalhadamente em Apêndice D.
O Esquema XML define doze propriedades, as quais são listadas em Apêndice
B. Entre elas, a propriedade enumeration
é de especial utilidade e pode ser utilizada para restringir os valores de quase
todos os tipos simples, excepto os do tipo boolean
.
A propriedade enumeration
limita um tipo simples a um conjunto de valores distintos. Por exemplo, nós
podemos utilizar a propriedade enumeration
,
a fim de definir um novo tipo simples denominado USState
, derivado
do tipo string
,
cujo valor deverá consistir numa das abreviaturas estaduais standard dos EUA:
USState
seria uma boa substituição para o tipo string
,
correntemente utilizado na declaração do elemento state
. Através da
referida substituição, os valores legais do elemento state
ou seja,
os sub-elementos de state
, em billTo
e
shipTo
, estariam limitados a algum valor de AK
,
AL
, AR
, etc. Note que os valores da enumeração que
foram específicados para um determinado tipo deverão ser únicos.
O Esquema XML tem o conceito de um tipo de lista, a adicionar aos assim
denominados tipos atómicos, os quais constituem a maioria dos tipos listados no
Quadro
2. (Os tipos atómicos, os tipos de lista e os tipos de união, todos eles
descritos na próxima secção, são colectivamente denominados de tipos simples.)
Segundo a perspectiva apresentada pelo Esquema XML, o valor de um tipo atómico é
indivisível.Por exemplo, o valor de NMTOKEN
denominado de US
é indivisível, no sentido em que nenhuma parte de
US
, tal como por exemplo o caractére "S", fará sentido por si
própria, senão e apenas no seu todo. Contrastando com o aspecto acima referido,
os chamados tipos (de) lista são compostos por sequências de tipos atómicos o
que significa que, consequentemente, as partes de uma sequência (os chamados
"átomos") só por si próprias possuem um significado lógico. Por exemplo,
NMTOKENS
é um tipo de lista, e um elemento deste tipo seria uma lista de elementos
NMTOKEN
’s,
delimitados por espaços em branco, tais como "US UK FR". O Esquema XML tem três
tipos de lista integrados (built-ins), respectivamente NMTOKENS
,
IDREFS
e ENTITIES
.
Além de utilizar esses tipos de lista integrados, você poderá criar
novos tipos de lista, derivando os tipos atómicos existentes. (Você não poderá
criar tipos de lista a partir de tipos de lista já existentes, apenas a partir
dos tipos complexos.) Por exemplo, para criar uma lista de elementos
myInteger
’s:
Um dos elementos contidos num documento de instância cujo conteúdo está em
conformidade com listOfMyIntType
é:
<listOfMyInt>20003 15037 95977 95945</listOfMyInt>
Poder-se-ão aplicar várias propriedades aos chamados tipos de lista:
length
,
minLength
,
maxLength
,
pattern
,
e enumeration
.
Por exemplo, para definirmos uma lista com nada mais nada menos do que seis
Estados americanos (SixUSStates
), teremos primeiramente de definir
um novo tipo de lista chamada USStateList
, a partir de
USState
e derivar então SixUSStates
, restringindo
USStateList
a apenas seis elementos:
Os elementos cujo tipo seja SixUSStates
têm de conter seis
itens, devendo ainda cada um desses itens ser um dos valores (atómicos)
pertencentes ao tipo USState
, como por exemplo:
<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:
Asia Europa Africa
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 tipos atómicos e os tipos de lista permitem que o valor de um
elemento ou atributo seja respectivamente uma ou mais instâncias pertencentes a
um tipo atómico. Contrastando com o ponto acima referido, o tipo de união
permite que o valor de um elemento ou atributo seja respectivamente uma ou mais
instâncias de um tipo formado pela união de múltiplos tipos atómicos e tipos de
lista.Para ilustrar esta definição, nós criámos um tipo de união para
representar os Estados Unidos na qualidade de abreviações de letras únicas ou
listas de códigos numéricos. O tipo de união zipUnion
é construído
a partir de um tipo atómico e de um tipo de lista:
Quando nós definimos um tipo de união, o valor do atributo
memberTypes
≈[tiposMembros] consiste numa lista, onde são referidos
todo os tipos contidos nessa união.
Agora, partindo do princípio que declarámos um elemento chamado
zips
, do tipo zipUnion
, as instâncias válidas deste
elemento são:
<zips>CA</zips> <zips>95630 95977 95945</zips> <zips>AK</zips>
Poderão ser aplicadas duas propriedades (do Inglês "facets")ao tipo de união,
nomeadamente pattern
e enumeration
.
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.
Consideremos primeiramente a forma como declarar um elemento que contenha um atributo e que seja do tipo simples. Num documento de instância, tal documento poderá aparecer sob a forma de:
<internationalPrice currency="EUR">423.46</internationalPrice>
O esquema da nota de encomenda especifica o elemento USPrice
, o
qual é ainda um ponto básico ou de partida:
<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.
A construção do esquema da ordem de encomenda pode ser caracterizada e definida como elementos contendo sub-elementos, e os sub-elementos dos níveis mais profundos contêm apenas dados formados por caractéres. O Esquema XML também possibilita a construção de esquemas, nos quais os dados constituídos por caractéres não possam aparecer lado a lado com os sub-elementos ou ainda que esses mesmos dados não se restrinjam aos sub-elementos dos níveis mais profundos.
Para ilustrar este aspecto, consideremos o fragmento seguinte, extraído da carta de um cliente que utiliza alguns dos mesmos elementos contidos na nota de encomenda:
Note-se que o texto aparece entre os elementos e os elementos derivados. Mais
específicamente, o texto aparece entre os elementos salutation
,
quantity
, productName
e shipDate
, os
quais são nomeadamente as derivadas do elemento letterBody
, e ainda
ao redor do elemento name
, o qual é a derivada da derivada do
elemento letterBody
. O fragmento do esquema que se segue declara ou
especifica o elemento letterBody
:
Os elementos que aparecem na carta do cliente são declarados e os seus tipos
são definidos usando as construções do tipo element
e complexType
,
as quais tivémos anteriormente a oportunidade de ver. Para possibilitar que os
dados formados por caractéres possam aparecer entre os elementos derivados do
elemento letterBody
, o atributo mixed
,
contido na definição do tipo, é definido como [true (verdadeiro)].
Note que o modelo mixed
contido no Esquema XML difere
fundamentalmente do Modelo Misto
XML 1.0. No modelo misto do Esquema XML, a ordem e o número dos elementos
derivados que aparecem numa instância devem estar em concordância com a ordem e
número dos elementos derivados que são especificados no modelo. Contrastando com
o caso anterior, no modelo misto do Esquema XML 1.0, a ordem e o número de
elementos derivados que aparecem na instância não poderão ser restringidos ou
limitados. Sumáriamente, o Esquema XML fornece uma validação integral dos
modelos mistos, contrastando pois com a validação parcial do esquema que nos é
fornecido em XML 1.0.
Suponhamos agora que pretendemos que o elemento
internationalPrice
contenha simultâneamente a unidade monetária e o
preço na qualidade dos valores dos atributos, em vez de termos dois valores
separados, ou seja, atributo e conteúdo. Por exemplo:
<internationalPrice currency="EUR" value="423.46"/>
Este elemento não possui qualquer tipo de conteúdo; o modelo do seu conteúdo está vazio. Para definir um tipo cujo conteúdo esteja vazio, nós defenimos essencialmente um tipo que permita apenas elementos no seu conteúdo, mas não declaramos factualmente qualquer um desses elementos, de forma que o modelo do seu conteúdo estará vazio:
Neste exemplo, nós definimos um tipo (anónimo) contendo um conteúdo do tipo
complexContent
, ou seja, apenas elementos only. O elemento
complexContent
sinaliza o facto de nós pretendermos limitar ou
alargar o modelo do conteúdo de um tipo complexo, e a restrição
do
elemento anyType
declara dois atributos mas não apresenta qualquer
conteúdo para o elemento (ver Derivando
Tipos Complexos por Restrição (§4.4) para informações mais detalhadas acerca
dos limites ou restrições). O elemento internationalPrice
que é
desta forma declarado, poderá aparecer legítimamente numa instância, como foi
exemplificado no exemplo acima dado.
A sintaxe precedente a um elemento com um conteúdo vazio é relativamente
detalhada e é possível declarar o elemento internationalPrice
de
uma maneira mais compacta:
Esta síntaxe compactada funciona dado que um tipo complexo que seja definido
sem qualquer tipo de conteúdo do tipo simpleContent
ou
complexContent
é interpretado como uma abreviatura do conteúdo
complexo que restringe o elemento anyType
.
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.
Suponhamos que nós pretendemos fornecer informações adicionais acerca de cada
um dos itens contidos na nota de encomenda, como por exemplo o peso de cada um
dos itens ou produtos vendidos, bem como o método de pagamento preferido. Nós
poderemos realizar essa tarefa adicionando as declarações dos atributos
weightKg
e shipBy
à definição do tipo dos elementos
contidos em item
(anónimo):
Alternativamente, nós poderemos criar um grupo de atributos nomeado
(ao qual foi, por assim dizer, atribuído um nome) contendo todos os desejados
atributos do elemento item
, e referenciar esse mesmo grupo através
do seu nome na declaração do elemento item
:
Usando-se um grupo de atributos desta forma poder-se-á melhorar a legibilidade dos esquemas e facilitar a actualização dos esquemas, uma vez que um grupo de atributos poderá ser definido e editado apenas num determinado local e referenciado em múltiplas definições e declarações. Essas características dos grupos de atributos torna-as distintas para as entidades dos parâmetros contidos em XML 1.0. Note no entanto que um grupo de atributos poderá conter outros grupos de atributos. É ainda de salientar que tanto as declarações de atributos como as referências aos grupos de atributos devem aparecer posicionadas no fim das definições do tipo complexo.
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.
Para vermos como se preenche o espaço-nominal de destino deste esquema, nós
examinaremos um pouco em torno de cada uma das definições do tipo e declarações
de elementos. Começando a partir do fim do esquema, nós definimos primeiramente
um tipo de atributo chamado USAddress
, o qual é constituído pelos
elementos name
, street
, etc. Uma das consequências
deste tipo de definição assenta no facto do tipo USAddress
estar
incluído no espaço-nominal de destino deste esquema. Em seguida, definiremos um
tipo chamado PurchaseOrderType
, o qual é constituído pelos
elementos shipTo
, billTo
, comment
, etc. O
elemento PurchaseOrderType
também está incluído no espaço-nominal
de destino deste esquema. Repare que as referências dos tipos contidas nas três
declarações dos elementos são prefixadas, nomeadamente
po:USAddress
, po:USAddress
e po:comment
,
e que o prefixo está associado ao espaço-nominal
http://www.example.com/PO1
. Este espaço-nominal é igual ao
espaço-nominal de destino, de forma que o processador deste esquema saberá fazer
a distinção entre o esquema da definição do tipo USAddress
e a
declaração do elemento comment
. Também é possível fazer a
referência a tipos contidos num outro esquema, o qual contenha um espaço-nominal
de destino diferente, possibilitando assim a reutilização das declarações e das
definições entre os esquemas.
No princípio do esquema po1.xsd
,
nós declarámos os elementos purchaseOrder
e comment
.
Eles estão incluídos nos espaços-nominais de destino dos referidos esquemas. O
tipo de elemento purchaseOrder
contém um prefixo, pela mesma razão
que USAddress
também contém um prefixo. Contrastando com este
facto, o tipo do elemento comment
, string
,
não é prefixado. O esquema po1.xsd
contém uma declaração de um espaço-nominal atribuída por defeito, de forma que
os tipos que não contenham prefixos, tais como string
e eleemntos não prefixados, tais como element
e complexType
estão associados ao espaço-nominal por defeito
http://www.w3.org/2001/XMLSchema
. Este é de facto o espaço-nominal
de destino do próprio Esquema XML, de forma que o processador do po1.xsd
reconhecerá o esquema do Esquema XML -- também conhecido como "esquema para os
esquemas" –- para a definição do tipo string
e a declaração do elemento chamado element
.
Examinemos agora a forma como os espaços-nominais contidos no esquema afectam um documento de instância em conformidade:
O documento de instância declara um espaço-nominal,
http://www.example.com/PO1
e associa-o ao prefixo
apo:
. Este prefixo é usado para qualificar dois elementos contidos
no documento, nomeadamente purchaseOrder
e comment
.
Este espaço-nominal é igual ao espaço-nominal de destino do esquema em po1.xsd
,
de forma que o processador do documento de instância reconhecerá esse esquema no
caso das declarações dos elementos purchaseOrder
e
comment
. De facto, os espaços-nominais são assim nomeados, no
sentido em que existe um espaço-nominal para os elementos
purchaseOrder
e comment
. Os espaços-nominais de
destino contidos no esquema controlam por isso a validação dos espaços-nominais
correspondentes na instância.
O prefixo apo:
é aplicado aos elementos globais
purchaseOrder
e comment
. Além disso, a presença de
elementFormDefault
e attributeFormDefault
requer que o prefixo não seja aplicado a nenhum dos elementos locais
declarados, tais como shipTo
, billTo
,
name
e street
, não sendo também aplicado a
nenhum dos atributos (os quais foram na sua totalidade localmente declarados).
Os elementos purchaseOrder
[nota de encomenda] e
comment
[comentário] são elementos globais, dado que eles são
declarados dentro do contexto esquema como um todo e não sob a forma de um tipo
específico ou particular. Por exemplo, a declaração de
purchaseOrder
aparece na qualidade de derivada do elemento schema
em po1.xsd
,
ao passo que a declaração do elemento shipTo
aparece como derivada
do elemento complexType
,
o qual define PurchaseOrderType
.
Sempre que não seja necesário que os elementos e os atributos locais sejam
qualicados, o autor do documento de instância requer algum conhecimento acerca
dos detalhes do esquema, de forma a poder criar documentos de instância com um
esquema válido. Mais específicamente, se o autor puder estar certo que apenas o
elemento da raíz (tal como por exemplo purchaseOrder
) é global, ele
terá então de qualificar apenas esse elemento da raíz. Como alternativa, o autor
poderá ter o conhecimento de que todos os elementos foram globalmente
declarados, de forma que todos os elementos contidos no documento de instância
poderão ser prefixados, tirando assim talvez alguma vantagem da declaração dos
espaços-nmominais atribuídos por defeito.(Nós examinamos esta aproximação mais
detalhadamente no Tema Declarações
Globais vs. Declarações Locais.) Por outro lado, se não existir nenhum
padrão uniforme relativo às declarações globais e locais, o autor necessitará de
conhecimentos detalhados acerca do esquema, de forma a poder aplicar
correctamente um prefixo aos elementos e atributos globais.
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
:
O ficheiro que contém a construção do endereço intitula-se:
A várias notas de encomenda e construções dos endereços estão agora
contidas em dois ficheiros contendo os referidos esquemas, nomeadamente ipo.xsd
e address.xsd
.
Para considerar essas mesmas construções como parte da nota de encomenda
internacional, ou seja, para incluí-las no espaço-nominal da nota de encomenda,
ipo.xsd
terá de conter o elemento include
:
<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.
A somar ao método de derivação de novos tipos complexos através da extensão ou do prolongamento dos modelos dos conteúdos, é ainda possível derivar novos tipos através da restrição dos modelos de conteúdos dos tipos já existentes. A restrição dos tipos complexos é conceitualmente igual à restrição dos tipos simples, excepto que a restrição dos tipos complexos envolvem o tipo de declaração em vez de envolver uma escala de valores aceitáveis para o tipo simples. Um tipo complexo que seja derivado por restrição é bastante similar ao seu tipo básico, excepto que a sua declaração é mais limitada do que as declarações correspondentes aos tipos básicos (a partir dos quais ele foi derivado). De facto, os valores representados pelo novo tipo são respectivamente um sub-conjunto dos valores representados pelo tipo básico (como é o caso como é o caso com a limitação dos tipos simples). Por outras palavras, uma aplicação que seja preparada para os valores do tipo básico não será surpreendida ou importunada pelos valores de um tipo limitado.
Suponhamos por exemplo, que nós pretendemos actualizar a definição
da nossa nota de encomenda, de forma que ela necessite assim de conter o
elemento comment
; o esquema que nos é exibido em ipo.xsd
permite que um elemento do tipo purchaseOrder
apareça sem quaisquer
derivadas do tipo comment
Para criarmos o nosso novo tipo
RestrictedPurchaseOrderType
[NotadeEncomendaRestringida], nós
definimo-lo da forma habitual, indicando que ele foi derivado pela restrição do
tipo simples PurchaseOrderType
, e atribuímos-lhe um novo valor
(mais restringente) para o número mínimo de ocorrências do elemento
comment
. Note no entanto que os tipos derivados por restrição
deverão conter a repetição de todos os componentes das partículas (declarações
dos elementos, grupos de modelos e wildcards) da definição do tipo básico a ser
incluída no tipo de derivada. Contudo, as declarações dos atributos não
necessitam de ser repetidas na definição do tipo derivado; neste caso, o
elemento RestrictedPurchaseOrderType
herdou a declaração do
atributo orderDate
pertencente a PurchaseOrderType
.
Esta alteração delimita o número aceitável de elementos comment
de 0 (mínimo) até 1. Note-se que todos os elementos do tipo
RestrictedPurchaseOrderType
também serão aceites como sendo
elementos do tipo PurchaseOrderType
.
Com vista a uma melhor ilustração das restrições, no Quadro 3 ser-lhe-ão exibidos vários exemplos de como as declarações dos elementos e atributos poderão ser limitadas dentro das definições dos tipos (o quadro mostra-nos a sintaxe dos elementos embora os três primeiros exemplos sejam igualmente restrições válidas para os atributos).
Quadro 3. Exemplos de Restrições | ||||||
---|---|---|---|---|---|---|
Restrições | Básicas | Notas | ||||
default="1" | estipular um valor por defeito, onde não se tenha atribuído ainda nenhum valor | |||||
fixed="100" | estipular um valor efectivo, onde não tenha ainda atribuído nenhum valor | |||||
type="string" | especificando um tipo, onde não se tenha ainda especificado nenhum | |||||
(minOccurs, maxOccurs) | (minOccurs, maxOccurs) | |||||
(0, 1) | (0, 0) | exclusão de um elemento opcional; esta acção também poderá ser concluída através da omissão da declaração dos componentes da definição do tipo que foi restrito ou limitado | ||||
(0, 1) | (1, 1) | a criação de um elemento opcional requer | ||||
(0, ilimitado) |
|
|||||
(1, 9) |
|
|||||
(1, ilimitado) |
|
|||||
(1, 1) | (1, 1) | não se podem restringir minOccurs ou maxOccurs |
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.
O Esquema XML fornece-nos um mecanismo intitulado de grupos de
substituição, o qual permite que os elementos possam ser substituídos por outros
elementos. Falando de uma forma mais detalhada, os elementos poderão ser
definidos para um grupo especial de elementos, os quais se pressupõe serem
substituíveis por elementos particularmente nomeados de elementos de cabeçalho.
(Note que os elementos de cabeçalho, tal como os eleemntos substituíveis deverão
ser declarados na qualidade de elementos globais.) Para ilustrar este caso, nós
declarmos dois elementos, intitulados customerComment
e
shipComment
e designámo-los para um grupo de substituição, cujo
elemento de cabeçalho é comment
, de forma que tanto
customerComment
como shipComment
poderão ser
utilizados em qualquer um dos sítios onde nós possamos utilizar
comment
. Os elementos contidos num grupo de substituição deverão
possuir o mesmo tipo que o elementos do cabeçalho ou ainda um tipo que tenha
sido derivado do tipo do elemento do cabeçalho. Para declarar esses dois novos
elementos e para os tornar substituíveis pelo elemento comment
, nós
utilizamos o seguinte sintaxe:
Sempre que estas declarações sejam adicionadas ao esquema da nota de
encomenda internacional, os elementos shipComment
e
customerComment
poderão ser substituídos pelo elemento
comment
no documento de instância, por exemplo:
.... <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
.
Até aqui, nós fomos capazes de derivar novos tipos e de utilizá-los em documentos de instância sem qualquer tipo de restrições.Em realidade, os autores de esquemas quererão controlar as derivações de determinados tipos, bem como o uso dos tipos derivados nas instâncias.
O Esquema XML fornece-nos um par de mecanismos que controlam a derivação dos
tipos. Um desses mecanismos permite ao autor do esquema especificar que,
relativamente a um tipo complexo em particular, novos tipos poderão não ser
derivados a partir dele, quer seja por restrição, (b) por extensão, ou (c) de
forma alguma. Para ilustrar este caso, suponhamos que nós queremos evitar
qualquer derivação por restrição do tipo Address
, dado que nós
pretendemos que ele seja apenas utilizado como base para os tipos prolongados,
como por exemplo USAddress
e UKAddress
. Para prever
assim qaulquer uma dessas derivações, nós alterámos ligeiramente a definição
original de Address
, como no exemplo que se segue:
O valor restriction
, pertencente ao atributo final
,
impede as derivações dos tipos por restrição. A prevenção das derivações de
forma alguma, ou por extensão, é-nos respectivamente indicada pelos valores
#all
e extension
. Existe ainda um atributo opcional,
finalDefault
,
contido no elemento schema
,
cujo valor poderá ser um dos valores permitidos para o atributo final
.
O efeito obtido pela especificação do atributo finalDefault
é igual ao efeito obtido pela especificação do atributo final
em cada definição de tipo e declaração de elementos contidos no esquema.
Um outro mecanismo de controlo da derivação de tipos, cujas
propriedades poderão ser aplicadas na derivação de um novo tipo simples. Quando
um novo tipo é definido, o atributo fixed
poderá ser aplicado a cada uma das suas propriedades (facets) de forma a
prevenir que a derivação desse tipo modifique o valor das propriedades fixas
(facets). Nós poderemos por exemplo definir o tipo simples Postcode
da seguinte forma:
Uma vez que este tipo simples tenha sido definido, nós poderemos derivar um novo tipo de código postal, no qual nós aplicaremos uma propriedade (facet) não fixa á definição da base, por exemplo:
De qualquer das maneiras, nós não poderemos derivar um novo código postal no qual nós voltamos a aplicar uma qualquer propriedade estabelecida na definição da base:
Em adição ao mecanismo que controla as derivações dos tipos, o
Esquema XML fornece-nos ainda um mecanismo que controla quais os grupos de
derivação e de substituição que poderão ser utilizados nos documentos de
instância. No Capítulo Usando
Tipos Derivados nos Documentos de Instância (§4.3), nós descrevemos a forma
como os tipos derivados, USAddress
e UKAddress
,
poderiam ser usados pelos elementos shipTo
e billTo
nos documentos de instância. Esses tipos derivados podem substituir o modelo de
conteúdo fornecido pelo tipo Address
, uma vez que eles são
derivados a partir do tipo Address
. Contudo, as substitições
efectuadas pelos tipos derivados podem ser controladas, através do uso do
atributo block
,
na definição do tipo. Por exemplo, se nós quisermos impedir que qualquer uma das
derivações por restrição seja usada em vez de Address
(talvez pela
mesma razão que nós definimos Address
com o atributo final="restriction"
),
nós poderemos alterar a definição original de Address
, como no
exemplo que se segue:
O valor de restrição
contido no atributo block
evita que as derivações por restrição substituiam o elemento
Address
na instância. Isso não evitará contudo que
UKAddress
e USAddress
substituiam
Address
, uma vez que eles são derivados por extensão. A prevenção
das derivações de forma alguma, ou por por extensão, é-nos respectivamente
indicada pelos valores #all
e extension
. Tal como no
caso do atributo final
,
existe um atributo opcional blockDefault
contido no elemento schema
,
cujo valor poderá ser um dos valores permitidos para o atributo block
.
O efeito obtido pela especificação do atributo blockDefault
é equivalente ao efeito obtido pela especificação do atributo block
em cada definição de tipo e declaração de elementos contidos no esquema.
O efectuamento dos pedidos e a sua facturação podem gerar relatórios ad-hoc
que sumarizem a quantidade de cada tipo de produto que foi facturada para cada
uma das regiões base. Um exemplo de tal relatório, cobrindo o quarto trimestre
de 1999, é-nos exibido no ficheiro 4Q99.xml
.
Note-se que nesta secção nós usámos elementos qualificados no esquema e que os espaços-nominais por defeito eram possibilitados nas instâncias.
Neste relatório são listados, de acordo com o seu número e a sua quantidade,
as partes facturadas pelos vários códigos postais, fornecendo-nos ainda a
descrição de cada uma das partes mencionadas. Ao sumariar a factura, a intenção
do relatório é clara e os dados não são ambíguos, dado que existem umas quantas
restrições. Por exemplo, cada código postal aparece apenas uma vez (restrição de
unicidade). Similarmente, a descrição de cada uma das partes facturadas aparece
apenas uma vez, se bem que essas partes possam ser facturadas para vários
códigos postais (restrição referencial), como por exemplo a parte número
455-BX
. Nas próximas secções, nós analisaremos a forma como
especificar essas restrições usando o Esquema XML.
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 key
s
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
:
Usando este novo tipo, nós declaramos o elemento chamado
analyst
, como sendo parte da declaração do elemento
purchaseReport
(a declaração não é exibida) no esquema do
relatório.Assim, o documento de instância que agora se segue, estaria em
conformidade com o esquema do relatório que foi modificado:
Note que o relatório contém agora tanto os elementos qualificados como os
elementos não qualificados. Isto dá-se ao facto dos elementos
(name
, street
, city
, state
e
zip
) serem localmente declarados em ipo.xsd
,
cujo elemento elementFormDefault
é definido como
unqualified
(por defeito). Os outros elementos contidos no examplo,
são declarados em report.xsd
,
cujo elemento elementFormDefault
é definido como
qualified
(qualificado).
Sempre que os componentes dos esquemas sejam importados a partir de vários
espaços-nominais, cada espaço-nominal deverá ser identificado com um elemento
import
em separado. Os elementos do tipo import
deverão eles próprios aparecer como primeira derivada do elemento schema
.
Além disso, a cada espaço-nominal deverá ser associado um prefixo. Para isso
utiliza-se uma declaração standard do espaço-nominal e um prefixo para
qualificar as referências a qualquer um dos componentes do esquema pertencentes
a esse espaço-nominal. Para finalizar, os elementos import
contêm opcionalmente o atributo schemaLocation
,
para ajudar a localizar os recursos associados aos espaços-nominais. Nós
discutiremos o atributo schemaLocation
mais detalhadamente, numa secção posterior.
À medida que os esquemas XML se tornam mais difundidos, os seus autores pretenderão criar tipos simples e complexos que possam ser partilhados e utilizados como blocos de construção na criação de novos esquemas. Os Esquemas XML fornecem-nos os tipos que desempenham esse papel, particularmente os tipos descritos no Apêndice dos Tipos Simples e no Capítulo introdutório referente à Livraria com os variados Tipos.
Os autores dos esquemas quererão indubitávelmente criar as suas próprias livrarias de tipos, com vista a representar as unidades monetárias, unidades de medida, endereços de negócios, e por aí adiante. Cada uma dessas livrarias poderá consistir num esquema contendo uma ou mais definições, como por exemplo, um esquema contendo um tipo de unidade monetária:
Exemplo de um elemento aparecendo numa instância e possuíndo este tipo:
<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.
Nas secções anteriores, nós observamos vários mecanismos destinados extensão dos modelos de conteúdos dos tipos complexos. Por exemplo, um modelo de conteúdo misto poderá conter dados de carácter arbitrário adicionados aos elementos, ou por exemplo, o modelo de um conteúdo poderá conter elementos cujos tipos sejam importados a partir de espaços-nominais externos. De qualquer das maneiras, esses mecanismos fornecem controlos, respectivamente, muito alargados ou muito estreitos. O propósito desta secção é o de descrever um mecanismo flexível que permita que os modelos dos conteúdos possam ser extensos por qualquer dos elementos e atributos pertencentes a espaços-nominais especificados.
Para ilustrar este exemplo, consideremos uma versão do relatório trimestral
4Q99html.xml
,
no qual nós encaixámos uma representação XHTML correspondente às partes dos
dados XML. O conteúdo XHTML aparece como sendo o conteúdo do elemento
htmlExample
, e o espaço-nominal por defeito é alterado no elemento
XHTML mais exterior (table
) de forma a que todos os elementos XHTML
pertençam ao espaço-nominal XHTML, http://www.w3.org/1999/xhtml
:
De forma a permitir a aparição de XHTML no documento de instância,
nós modificamos o relatório do esquema, declarando o novo elemento
htmlExample
, cujo conteúdo é definido pelo elemento any
[qualquer]. De uma forma geral, o elemento any
especifica que qualquer XML que tenha sido bem construído ou estruturado será
permitido no modelo do conteúdo do tipo. Neste exemplo, nós requeremos que XML
pertença ao espaço-nominal http://www.w3.org/1999/xhtml
, por outras
palavras, ele tem ou deverá ser XHTML. Este exemplo também requer que exista
nele pelo menos um elemento pertencente a este espaço-nominal, como é indicado
pelos valores de minOccurs
e maxOccurs
:
A modificação permite que alguns XML bem construídos, pertencentes
ao espaço-nominal http://www.w3.org/1999/xhtml
, apareçam dentro do
elemento htmlExample
. Por isso mesmo, o uso de 4Q99html.xml
é permissível, dado que existe um elemento (conjuntamente com a sua derivada)
que é bem formado, o elemento aparece contido no elemento apropriado
(htmlExample
), e o documento de instância estipula que o elemento e
o sue conteúdo pertençam ao espaço-nominal requerido. Contudo, o XHTML poderá
realmente não ser válido, dado que nenhum elemento contido em 4Q99html.xml
poderá fornecer tal garantia. Se tal garantia for requerida, o valor do atributo
processContents
deverá ser definido ou ajustado como sendo strict
(valor
estabelecido por defeito do atributo). Neste caso, um processador XML é obrigado
a obter o esquema associado ao espaço-nominal requerido, e a validar o XHTML que
aparece contido no elemento htmlExample
.
Num outro exemplo, nós definimos um tipo text
, o
qual é similar ao tipo de texto definido na Livraria de
Introdução dos tipos do Esquema XML (ver também Livrarias
referentes aos Tipos (§5.4.1)), e é apropriado para o texto
internacionalizado apto à leitura humana. O tipo [text] permite-nos uma mistura
não limitada do conteúdo dos caractéres e elementos a partir de qualquer
espaço-nominal, como por exemplo as anotações Ruby, lado a lado com um atributo opcional
designado de xml:lang
. O valor lax
pertencente ao
atributo processContents
,
dá instruções ao processador XML para validar o conteúdo do elemento numa base
do tipo "can-do": ele validará elementos e atributos para os quais ele consiga
obter informações do esquema, mas não sinalizará erros para os quais ele não
consiga obter nenhuma informação referente ao esquema.
Os espaços-nominais poderão ser usados para permitir ou impedir que
o conteúdo dos elementos dependa de variadas formas do valor do atributo
namespace
,
como nos é exibido no Quadro
4:
Quadro 4. Atributo do Espaço-nominal em [Any] | |
---|---|
Valor do Atributo do Espaço-nominal | Conteúdo dos Elementos que é permitido |
##any | Qualquer XML que seja bem construído, a partir de qualquer espaço-nominal (por defeito) |
##local | Qualquer XML bem construído mas que não esteja qualificado ou seja, que não seja declarado para estar no espaço-nominal |
##other | Qualquer elemento XML bem formado que pertença a um outro espaço-nominal que não o espaço-nominal de destino do tipo a ser definido (elementos não qualificado não são aqui permitidos) |
"http://www.w3.org/1999/xhtml ##targetNamespace" | Qualquer XML bem formado, pertencente a qualquer espaço-nominal contido na lista (separada por espaços em branco); ##targetNamespace é a forma abreviada para o espaço-nominal de destino do tipo a ser definido |
A adicionar ao elemento any
o qual permite que o conteúdo dos elementos esteja de acordo com os
espaços-nominais, existe um atributo a ele correspondente, designado de anyAttribute
,
o qual permite que os atributos possam aparecer contidos nos elementos. Por
exemplo, nós permitir que qualquer atributo XHTML apareça como parte do elemento
htmlExample
, somando anyAttribute
à sua declaração:
Esta declaração permite que um atributo XHTML, digamos por exemplo
href
, apareça contido no elemento htmlExample
. Por
exemplo:
O atributo namespace
contido num elemento anyAttribute
poderá ser ajustado ou definido por qualquer um dos valores listados no Quadro
4 para o elemento any
,
e o atributo anyAttribute
poderá ser especificado com um atributo processContents
.
Contrastando com o elemento any
,
o atributo anyAttribute
não poderá restringir o número de atributos que podem aparecer num elemento.
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
, UKAddress
e
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).
Um documento de instância pode ser processado contra um esquema, a fim de se verificar se as regras especificadas no esquema são cumpridas na instância. Tipicamente, tal processo baseia-se em duas acções: (1) verifica a concordância para com as regras, num processo intitulado de validação do esquema, e (2) adiciona informação suplementar, a qual não está logo de imediato presente na instância, como por exemplo os valores dos tipos e os valores atribuídos por defeito, intitulados de contribuições informativas.
O autor de um documento de instância, com por exemplo uma nota de encomenda
particular, poderá especificar, ainda na própria instância, que ela esteja em
concordância com as regras de um esquema em particular. O autor poderá fazê-lo
usando o atributo schemaLocation
,
o qual foi já mais acima discutido. Contudo, não atendendo ao facto se o
atributo schemaLocation
está ou não presente, uma aplicação é livre de processar o documento contra
qualquer esquema. Por exemplo, a aplicação de um pedido poderá ter como
política, o facto de utilizar um determinado esquema da nota de encomenda, não
atendendo a nenhum dos valores do atributo schemaLocation
.
A verificação dessa concordância poderá ser realizada em vários passos, verificando-se primeiro se o elemento da raíz da instância do documento possui os conteúdos certos, e depois a conformidade de cada sub-elemento segundo a sua descrição no esquema e por aí adiante, até que o documento tenha sido verificado por completo. Os processadores são aqui requeridos para confirmar o tipo de de comprovações que levaram a cabo.
Para verificar a conformidade de um elemento, o processador localiza
primeiramente a declaração do elemento contidos no esquema, verificando depois
se o atributo targetNamespace
contido no esquema corresponde ao actual espaço-nominal URI do elemento.
Alternativamente, ele poderá determinar que o esquema não contém o atributo
,
targetNamespace
e que o elemento da instância não está qualificado no
que se refere ao seu espaço-nominal.
Supondo que o espaço-nominal preenche os requesitos, o processador examinará
então o tipo do elemento, quer segundo o definido pela declaração contida no
esquema, ou pelo atributo xsi:type
contido na instância. Se se verificar este último caso, o tipo da instância
deverá consistir numa substituição permitida para o tipo indicado no esquema;
tudo aquilo que é permitido é controlado pelo atributo block
,
contido na declaração do elemento. Ao mesmo tempo, os valores atribuídos por
defeito e outras contribuições informativas serão devidamente aplicados.
De seguida, o processador verifica os atributos imediatos e os conteúdos do
elemento, comparando-os aos atibutos e conteúdos permitidos pelo tipo do
elemento. Por exemplo, considerando o elemento shipTo
, tal como o
que poderá ser encontrado na Nota
de Encomenda (§2.1), o processador verifica quais as condições permitidas
para Address
, uma vez que shipTo
é, nomeadamente, o
tipo do elemento.
Se o elemento possuir um tipo simples, o processador verificará se o elemento não contém atributos ou elementos nele contidos, e que o conteúdo dos seus caractéres preenche as regras definidas para os tipos simples. Tal facto envolve por vezes a verificação da sequência dos caractéres, face às expressões regulares ou enumerações, e ainda se a mesma sequência dos caractéres representa o valor permitido numa determinada escala de valores.
Se o elemento possuir um tipo complexo, então o processador verificará se todos os atributos requeridos se encontram presentes e se os seus valores estão em conformidade com os requesitos dos seus tipos simples. Ele verificará ainda se todos os sub-elementos requeridos se encontram presentes e se a sequência dos sub-elementos (e de qualquer texto misto) corresponde e preenche os requesitos necessários do modelo de conteúdo que foi declarado para o tipo complexo. Olhando aos sub-elementos, os esquemas podem requerir uma combinação nominal exacta, permitir que os elementos sejam substituídos por elementos equivalentes ou substituidos por qualquer elemento, facto que é permitido através do uso da partícula "any".
A menos que o esquema indique o contrário ( como o poderá fazer no caso das partículas "any", a verificação da concordância prosseguirá então a um nível mais avançado, inspeccionando os elemento um por um, repetindo o todo processo acima descrito.
Muitas foram as pessoas que contribuíram com as suas ideias, materiais e feedback, os quais melhoraram este documento. O editor deste documento gostaria de agradecer especialmente as contribuições de David Beech, Paul Biron, Don Box, Allen Brown, David Cleary, Dan Connolly, Roger Costello, Martin Dürst, Martin Gudgin, Dave Hollander, Joe Kesselman, John McCarthy, Andrew Layman, Eve Maler, Ashok Malhotra, Noah Mendelsohn, Michael Sperberg-McQueen, Henry Thompson, Misha Wolf, e Priscilla Walmsley, pelo facto de eles terem validado os exemplos.
Pela altura em que a primeira edição desta especificação foi publicada, os membros pertencentes ao Grupo de Trabalho do Esquema XML foram nomeadamente:
O Grupo de Trabalho do Esquema XML beneficiou da participação e da contribuição de um número de pessoas, as quais não fazem actualmente parte do referido Grupo, incluindo as já acima mencionadas. As afiliações que foram dadas correspondem à data do seu trabalho conjunto com a WG.
As listas que foram acima fornecidas correspondem à primeira edição. Pela altura em que o trabalho nesta segunda edição foi terminado, o Grupo de Trabalho foi formado por:
Gostaríamos ainda de salientar, com alguma tristeza, a morte acidental de Mario Jeckle, pouco depois do trabalho neste documento ter sido terminado. A adicionar aos nomes que foram acima mencionados, foram várias as pessoas que ajudaram o Grupo de Trabalho durante o desenvolvimento desta segunda edição:
Os valores legais para cada um dos tipos poderá ser limitado através da aplicação de uma ou mais propriedades (facets). Os Quadros B1.a e B1.b listam todos os tipos simples integrados (built-ins) do Esquema XML, bem como as propriedades aplicáveis a cada um dos tipos. Os nomes dos tipos simples e das suas características estão hiperligados às respectivas descrições em Esquema XML, Parte 2: Tipos de dados.
Quadro B1.a Tipos Simples & Propriedades Aplicáveis | ||||||
---|---|---|---|---|---|---|
Tipos Simples | Propriedades | |||||
length [longitude] |
minLength | maxLength | pattern | enumeration (enumeração) | whiteSpace | |
string | y | y | y | y | y | y |
normalizedString(string normalizada) | y | y | y | y | y | y |
token | y | y | y | y | y | ver (1) |
base-binária-64 | y | y | y | y | y | ver (1) |
hexBinary | y | y | y | y | y | ver (1) |
integer | y | y | ver (1) | |||
positiveInteger | y | y | ver (1) | |||
negativeInteger | y | y | ver (1) | |||
nonNegativeInteger | y | y | ver (1) | |||
nonPositiveInteger | y | y | ver (1) | |||
long | y | y | ver (1) | |||
unsignedLong | y | y | ver (1) | |||
int | y | y | ver (1) | |||
unsignedInt | y | y | ver (1) | |||
short | y | y | ver (1) | |||
unsignedShort | y | y | ver (1) | |||
byte | y | y | ver (1) | |||
unsignedByte | y | y | ver (1) | |||
decimal | y | y | ver (1) | |||
float | y | y | ver (1) | |||
double | y | y | ver (1) | |||
boolean | y | ver (1) | ||||
duration (duração) | y | y | ver (1) | |||
dateTime (dataHora) | y | y | ver (1) | |||
date (data) | y | y | ver (1) | |||
time (hora) | y | y | ver (1) | |||
gYear | y | y | ver (1) | |||
gYearMonth | y | y | ver (1) | |||
gMonth | y | y | ver (1) | |||
gMonthDay | y | y | ver (1) | |||
gDay | y | y | ver (1) | |||
Name (Nome) | y | y | y | y | y | ver (1) |
QName | y | y | y | y | y | ver (1) |
NCName | y | y | y | y | y | ver (1) |
anyURI(qualquer URI) | y | y | y | y | y | ver (1) |
language (linguagem) | y | y | y | y | y | ver (1) |
ID | y | y | y | y | y | ver (1) |
IDREF | y | y | y | y | y | ver (1) |
IDREFS | y | y | y | y | y | ver (1) |
ENTIDADE | y | y | y | y | y | ver (1) |
ENTIDADES | y | y | y | y | y | ver (1) |
ANOTAÇÕES | y | y | y | y | y | ver (1) |
NMTOKEN | y | y | y | y | y | ver (1) |
NMTOKENS | y | y | y | y | y | ver (1) |
Nota: (1) Embora o "facet" do whiteSpace seja
aplicada a este tipo, o único valor que poderá ser especificado é o
collapse . |
As propriedades listadas no Quadro B1.b só se aplica aos tipos simples que sejam ordenados. Nem todos os tipos simples estão ordenados, de maneira que o Quadro B1.b não contém todos os tipos simples listados.
Quadro B1.b. Tipos Simples & Propriedades Aplicáveis | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipos Simples | Propriedades | |||||||||||||||||
|
|
|
|
|
| |||||||||||||
integer | y | y | y | y | y | ver (1) | ||||||||||||
positiveInteger | y | y | y | y | y | ver (1) | ||||||||||||
negativeInteger | y | y | y | y | y | ver (1) | ||||||||||||
nonNegativeInteger | y | y | y | y | y | ver (1) | ||||||||||||
nonPositiveInteger | y | y | y | y | y | ver (1) | ||||||||||||
long | y | y | y | y | y | ver (1) | ||||||||||||
unsignedLong | y | y | y | y | y | ver (1) | ||||||||||||
int | y | y | y | y | y | ver (1) | ||||||||||||
unsignedInt | y | y | y | y | y | ver (1) | ||||||||||||
short | y | y | y | y | y | ver (1) | ||||||||||||
unsignedShort | y | y | y | y | y | ver (1) | ||||||||||||
byte | y | y | y | y | y | ver (1) | ||||||||||||
unsignedByte | y | y | y | y | y | ver (1) | ||||||||||||
decimal | y | y | y | y | y | y | ||||||||||||
float | y | y | y | y | ||||||||||||||
double | y | y | y | y | ||||||||||||||
duration | y | y | y | y | ||||||||||||||
dateTime | y | y | y | y | ||||||||||||||
date | y | y | y | y | ||||||||||||||
time | y | y | y | y | ||||||||||||||
gYear | y | y | y | y | ||||||||||||||
gYearMonth | y | y | y | y | ||||||||||||||
gMonth | y | y | y | y | ||||||||||||||
gMonthDay | y | y | y | y | ||||||||||||||
gDay | y | y | y | y | ||||||||||||||
Nota: (1) Embora a propriedade fractionDigits
seja aplicável a este tipo, o único valor que poderá ser especificado é o
zero. |
O XML 1.0 fornece-nos vários tipos de entidades , as quais são em realidade fragmentos do conteúdo aos quais lhes foram dado um nome que poderá ser usado na construção dos DTD's (entidades dos parâmetros) e dos documentos de instância. No Capítulo Construindo os Modelos do Conteúdo (§2.7), nós reparámos na forma como os grupos nomeados mimetizam as entidades dos parâmetros. Nesta secção, nós exibiremos a forma como as entidades podem ser declaradas num documento de instância, bem como os equivalentes funcionais das entidades poderão ser declarados nos esquemas.
Suponhamos que nós queremos declarar e usar uma entidade num documento de instância e que esse documento também é restringido por um esquema. Por exemplo:
Aqui, nós declaramos uma entidade denominada eacute
parte de um
conjunto interno (DTD), e referenciamos essa entidade no conteúdo do elemento
city
. Note que quando este documento de instância é processado, a
entidade será resolvida antes da validação do esquema tomar lugar. Por outras
palavras, o processador do esquema determinará a validade do elemento
city
, usando Montréal
como sendo o valor do elemento.
Nós poderemos obter um efeito similar mas não idêntico, declarando um elemento num esquema e definindo o conteúdo do elemento da forma mais apropriada:
<xsd:element name="eacute" type="xsd:token" fixed="é"/>
Este elemento poderá ser utilizado num documento de instância:
Neste caso, o processador do esquema processará dois elementos, o elemento
city
e o elemento eacute
, para cujos os conteúdos o
processador fornecerá o caractére isolado é
. Note que os elementos
extras complicam as combinações das string; as duas formas do nome "Montréal"
que foram dadas nos dois exemplos acima não se irão influenciar, usando uma
técnica de comparação de strings normal.
A propriedade pattern
,
contida no Esquema XML, usa uma linguagem de expressão regular que suporta Unicode.
Ela é descrita na sua íntegra, no Documento Esquema
XML, Parte 2. A linguagem é similar à linguagem de expressão regular usada
na Linguagem de
Programação Perl, se bem que as expressões sejam aqui classificadas de
acordo com a totalidade das suas representações lexicais, em vez de serem
focalizadas de acordo com um lexico de utente, tais como linha e parágrafo. Por
esta razão, a linguagem da expressão não contém os metacaractéres ^ e $, embora
^ seja usado para expressar uma excepção, como por exemplo [^0-9]x.
Quadro D1. Exemplos de Expressões Regulares | |
---|---|
Expressão | Valores coincidentes |
Capítulo \d | Capítulo 0, Capítulo 1, Capítulo 2 .... |
Capítulo\s\d | Capítulo seguido de um único espaço em branco (espaço, tabulador, mudança de linha, etc), seguido de um único dígito |
Capítulo\s\w | Capítulo seguido de um único espaço em branco (espaço, tabulador, mudança de linha, etc), seguido de um caractére alfabético (XML 1.0 Letra ou Dígito) |
Española | Española |
\p{Lu | qualquer letra maíuscula, o valor de \p{} (exemplo: "Lu") é definido por Unicode |
\p{IsGreek | qualquer caractére do alfabeto Grego, a construção ‘ Is ' pode ser aplicada a qualquer bloco nominativo (exemplo: "Grego"), como o definido em Unicode |
\P{IsGreek | qualquer caractére não pertencente ao alfabeto Grego, a construção ‘ Is ' pode ser aplicada a qualquer bloco nominativo (exemplo: "Grego"), como o definido através de Unicode |
a*x | x, ax, aax, aaax .... |
a?x | ax, x |
a+x | ax, aax, aaax .... |
(a|b)+x | ax, bx, aax, abx, bax, bbx, aaax, aabx, abax, abbx, baax, babx, bbax, bbbx, aaaax .... |
[abcde]x | ax, bx, cx, dx, ex |
[a-e]x | ax, bx, cx, dx, ex |
[\-ae]x | -x, ax, ex |
[ae\-]x | ax, ex, -x |
[^0-9]x | qualquer caractére não numerativo, seguido do caractére x |
\Dx | qualquer caractére não numerativo, seguido do caractére x |
.x | qualquer caractére seguido do caractére x |
.*abc.* | 1x2abc, abc1x2, z3456abchooray .... |
ab{2}x | abbx |
ab{2,4}x | abbx, abbbx, abbbbx |
ab{2,}x | abbx, abbbx, abbbbx .... |
(ab){2}x | ababx |
Cada elemento nominativo é seguido de um ou mais Links com exemplos (identificados pelo número da secção) contidos nos Princípios Básicos, mais um Link para a descrição XML formal, tanto na especificação das partes das Extruturas como ainda nas dos Tipos dos Dados do Esquema XML .
all : [
(§2.7)] [Estruturas] |
annotation : [
(§2.6)] [Estruturas] |
any : [
(§5.5)] [Estruturas] |
anyAttribute : [
(§5.5)] [Estruturas] |
appinfo : [
(§2.6)] [Estruturas] |
attribute : [
(§2.2)] [Estruturas] |
attributeGroup : [
(§2.8)] [Estruturas] |
choice : [
(§2.7)] [Estruturas] |
complexContent : [
(§2.5.3)] [Estruturas] |
complexType : [
(§2.2)] [Estruturas] |
documentation : [
(§2.6)] [Estruturas] |
element : [
(§2.2)] [Estruturas] |
enumeration : [
(§2.3)] [Datatypes] |
extension : [
(§2.5.1)] [Estruturas],
[
(§4.2)] [Estruturas] |
field : [
(§5.1)] [Estruturas] |
group : [
(§2.7)] [Estruturas] |
import : [
(§5.4)] [Estruturas] |
include : [
(§4.1)] [Estruturas] |
key : [
(§5.2)] [Estruturas] |
keyref : [
(§5.2)] [Estruturas] |
length : [
(§2.3.1)] [Datatypes] |
list : [
(§2.3.1)] [Datatypes] |
maxInclusive : [
(§2.3)] [Datatypes] |
maxLength : [
(§2.3.1)] [Datatypes] |
minInclusive : [
(§2.3)] [Datatypes] |
minLength : [
(§2.3.1)] [Datatypes] |
pattern : [
(§2.3)] [Datatypes] |
redefine : [
(§4.5)] [Estruturas] |
restriction : [
(§2.3)] [Datatypes],
[
(§4.4)] [Estruturas] |
schema : [
(§2.1)] [Estruturas] |
selector : [
(§5.1)] [Estruturas] |
sequence : [
(§2.7)] [Estruturas] |
simpleContent : [
(§2.5.1)] [Estruturas] |
simpleType : [
(§2.3)] [Datatypes] |
union : [
(§2.3.2)] [Datatypes] |
unique : [
(§5.1)] [Estruturas] |
Cada nome de atributo é seguido de um ou mais pares de referências. Cada par de referências consiste numa hiperligação a um exemplo contido nos Princípios Básicos, mais um Link para a descrição XML formal, tanto na especificação das partes das Extruturas como ainda nas dos Tipos dos Dados do Esquema XML .
Os tipos simples contidos no Esquema XML são descritos no Quadro 2.