2.1 O Esquema da Nota de Encomenda

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

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

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

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

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

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

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

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

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

</xsd:schema>

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

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

2.2 Definições de Tipos Complexos, Declaração dos Elementos e dos Atributos

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

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

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

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.

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

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

2.3 Tipos Simples

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

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:

<xsd:simpleType name="myInteger">
  <xsd:restriction base="xsd:integer">
    <xsd:minInclusive value="10000"/>
    <xsd:maxInclusive value="99999"/>
  </xsd:restriction>
</xsd:simpleType>

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

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

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:

<xsd:simpleType name="USState">
  <xsd:restriction base="xsd:string">
    <xsd:enumeration value="AK"/>
    <xsd:enumeration value="AL"/>
    <xsd:enumeration value="AR"/>
    <!-- and so on ... -->
  </xsd:restriction>
</xsd:simpleType>

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.

<xsd:simpleType name="listOfMyIntType">
  <xsd:list itemType="myInteger"/>
</xsd:simpleType>

<listOfMyInt>20003 15037 95977 95945</listOfMyInt>

<xsd:simpleType name="USStateList">
  <xsd:list itemType="USState"/>
</xsd:simpleType>

<xsd:simpleType name="SixUSStates">
  <xsd:restriction base="USStateList">
    <xsd:length value="6"/>
  </xsd:restriction>
</xsd:simpleType>

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

Asia Europa Africa

Asia Europa América Latina

<xsd:simpleType name="zipUnion">
  <xsd:union memberTypes="USState listOfMyIntType"/>
</xsd:simpleType>

<zips>CA</zips>
<zips>95630 95977 95945</zips>
<zips>AK</zips>

2.4 Definições de Tipo Anónimo

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

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

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

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.

2.5 Conteúdo dos Elementos

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

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

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

<xsd:element name="internationalPrice">
  <xsd:complexType>
    <xsd:simpleContent>
      <xsd:extension base="xsd:decimal">
        <xsd:attribute name="currency" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>
</xsd:element>

<letterBody>
<salutation>Ex.mo Sr.<name>Robert Smith</name>.</salutation>
A sua encomenda com o <quantity>1</quantity> <productName>Monitor de Vigia p/bébés </productName> foi despachada no nosso armazém no dia
<shipDate>1999-05-21</shipDate>. ....
</letterBody>

<xsd:element name="letterBody">
  <xsd:complexType mixed="true">
    <xsd:sequence>
      <xsd:element name="salutation">
        <xsd:complexType mixed="true">
          <xsd:sequence>
            <xsd:element name="name" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="quantity"    type="xsd:positiveInteger"/>
      <xsd:element name="productName" type="xsd:string"/>
      <xsd:element name="shipDate"    type="xsd:date" minOccurs="0"/>
      <!-- etc. -->
    </xsd:sequence>
  </xsd:complexType>
</xsd:element>

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

<xsd:element name="internationalPrice">
  <xsd:complexType>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="currency" type="xsd:string"/>
        <xsd:attribute name="value"    type="xsd:decimal"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:element>

<xsd:element name="internationalPrice">
  <xsd:complexType>
    <xsd:attribute name="currency" type="xsd:string"/>
    <xsd:attribute name="value"    type="xsd:decimal"/>
  </xsd:complexType>
</xsd:element>

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

<xsd:element name="anything"/>

2.6 Anotações

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

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

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

<xsd:element name="internationalPrice">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
         elemento declarado com um tipo anónimo
    </xsd:documentation>
  </xsd:annotation>
  <xsd:complexType>
    <xsd:annotation>
      <xsd:documentation xml:lang="en">
           tipo anónimo vazio contendo dois atributos
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:restriction base="xsd:anyType">
        <xsd:attribute name="currency" type="xsd:string"/>
        <xsd:attribute name="value"    type="xsd:decimal"/>
      </xsd:restriction>
    </xsd:complexContent>
  </xsd:complexType>
</xsd:element>

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.

2.7 Construindo Modelos de Conteúdo

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

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

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

<xsd:complexType name="PurchaseOrderType">
  <xsd:sequence>
    <xsd:choice>
      <xsd:group   ref="shipAndBill"/>
      <xsd:element name="singleUSAddress" type="USAddress"/>
    </xsd:choice>
    <xsd:element ref="comment" minOccurs="0"/>
    <xsd:element name="items"  type="Items"/>
  </xsd:sequence>
  <xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>

<xsd:group id="shipAndBill">
  <xsd:sequence>
    <xsd:element name="shipTo" type="USAddress"/>
    <xsd:element name="billTo" type="USAddress"/>
  </xsd:sequence>
</xsd:group>

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:

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

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:

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

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.

2.8 Grupos de Atributos

<xsd:element name="item" minOccurs="0" maxOccurs="unbounded">
  <xsd:complexType>
    <xsd:sequence>
      <xsd:element   name="productName" type="xsd:string"/>
      <xsd:element   name="quantity">
        <xsd:simpleType>
          <xsd:restriction base="xsd:positiveInteger">
            <xsd:maxExclusive value="100"/>
          </xsd:restriction>
        </xsd:simpleType>
      </xsd:element>
      <xsd:element name="USPrice"  type="xsd:decimal"/>
      <xsd:element ref="comment"   minOccurs="0"/>
      <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute name="partNum"  type="SKU" use="required"/>
    <!-- add weightKg and shipBy attributes -->
    <xsd:attribute name="weightKg" type="xsd:decimal"/>
    <xsd:attribute name="shipBy">
      <xsd:simpleType>
        <xsd:restriction base="xsd:string">
          <xsd:enumeration value="air"/>
          <xsd:enumeration value="land"/>
          <xsd:enumeration value="any"/>
        </xsd:restriction>
      </xsd:simpleType>
    </xsd:attribute>
  </xsd:complexType>
</xsd:element>

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

    <!-- attributeGroup replaces individual declarations -->
    <xsd:attributeGroup ref="ItemDelivery"/>
  </xsd:complexType>
</xsd:element>

<xsd:attributeGroup id="ItemDelivery">
  <xsd:attribute name="partNum"  type="SKU" use="required"/>
  <xsd:attribute name="weightKg" type="xsd:decimal"/>
  <xsd:attribute name="shipBy">
    <xsd:simpleType>
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="air"/>
        <xsd:enumeration value="land"/>
        <xsd:enumeration value="any"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:attribute>
</xsd:attributeGroup>

2.9 Valores Nulos

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

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

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

3.1 Espaços-nominais de destino & Locais não qualificados

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

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

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

<schema xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.example.com/PO1"
        targetNamespace="http://www.example.com/PO1"
        elementFormDefault="unqualified"
        attributeFormDefault="unqualified">

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

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

  <complexType name="USAddress">
    <sequence>
      <element name="name"   type="string"/>
      <element name="street" type="string"/>
      <!-- etc. -->
    </sequence>
  </complexType>

  <!-- etc. -->

</schema>

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:

<?xml version="1.0"?>
<apo:purchaseOrder xmlns:apo="http://www.example.com/PO1"
                   orderDate="1999-10-20">
  <shipTo country="US">
    <name>Alice Smith</name>
    <street>123 Maple Street</street>
    <!-- etc. -->
  </shipTo>
  <billTo country="US">
    <name>Robert Smith</name>
    <street>8 Oak Avenue</street>
    <!-- etc. -->
  </billTo>
  <apo:comment>Rápido, o meu advogado está a ficar impaciente!<!/apo:comment>
  <!-- etc. -->
</apo:purchaseOrder>

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.

3.2 Locais Qualificados

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

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

<?xml version="1.0"?>
<apo:purchaseOrder xmlns:apo="http://www.example.com/PO1"
                   orderDate="1999-10-20">
  <apo:shipTo country="US">
    <apo:name>Alice Smith</apo:name>
    <apo:street>123 Maple Street</apo:street>
    <!-- etc. -->
  </apo:shipTo>
  <apo:billTo country="US">
    <apo:name>Robert Smith</apo:name>
    <apo:street>8 Oak Avenue</apo:street>
    <!-- etc. -->
  </apo:billTo>
  <apo:comment>Rápido, o meu advogado está a ficar impaciente!<!/apo:comment>
  <!-- etc. -->
</apo:purchaseOrder>

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:

<?xml version="1.0"?>
<purchaseOrder xmlns="http://www.example.com/PO1"
               orderDate="1999-10-20">
  <shipTo country="US">
    <name>Alice Smith</name>
    <street>123 Maple Street</street>
    <!-- etc. -->
  </shipTo>
  <billTo country="US">
    <name>Robert Smith</name>
    <street>8 Oak Avenue</street>
    <!-- etc. -->
  </billTo>
  <comment>Rápido, o meu advogado está a ficar impaciente!<!/comment>
  <!-- etc. -->
</purchaseOrder>

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:

<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">
  <!-- etc. -->
  <element name="secure">
    <complexType>
      <sequence>
        <!-- element declarations -->
      </sequence>
      <attribute name="publicKey" type="base64Binary" form="qualified"/>
    </complexType>
  </element>
</schema>

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:

<?xml version="1.0"?>
<purchaseOrder xmlns="http://www.example.com/PO1"
               xmlns:po="http://www.example.com/PO1"
               orderDate="1999-10-20">
  <!-- etc. -->
  <secure po:publicKey="GpM7">
    <!-- etc. -->
  </secure>
</purchaseOrder>

3.3 Declarações Globais vs. Declarações Locais

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

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

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

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

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

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

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

4.1 O Esquema em Documentos Variados

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

<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

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

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

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

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

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

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

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

</schema>

<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

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

  <complexType name="Address">
    <sequence>
      <element name="name"   type="string"/>
      <element name="street" type="string"/>
      <element name="city"   type="string"/>
    </sequence>
  </complexType>

  <complexType name="USAddress">
    <complexContent>
      <extension base="ipo:Address">
        <sequence>
          <element name="state" type="ipo:USState"/>
          <element name="zip"   type="positiveInteger"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

  <complexType name="UKAddress">
    <complexContent>
      <extension base="ipo:Address">
        <sequence>
          <element name="postcode" type="ipo:UKPostcode"/>
        </sequence>
        <attribute name="exportCode" type="positiveInteger" fixed="1"/>
      </extension>
    </complexContent>
  </complexType>

  <!-- other Address derivations for more countries -->

  <simpleType name="USState">
    <restriction base="string">
      <enumeration value="AK"/>
      <enumeration value="AL"/>
      <enumeration value="AR"/>
      <!-- and so on ... -->
    </restriction>
  </simpleType>

  <!-- simple type definition for UKPostcode -->

</schema>

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.

4.2 Derivando Tipos Complexos por Extensão

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

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

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

<complexType name="UKAddress">
  <sequence>
    <!-- content model of Address -->
    <element name="name"   type="string"/>
    <element name="street" type="string"/>
    <element name="city"   type="string"/>

    <!-- appended element declaration -->
    <element name="postcode" type="ipo:UKPostcode"/>
  </sequence>

  <!-- appended attribute declaration -->
  <attribute name="exportCode" type="positiveInteger" fixed="1"/>
</complexType>

4.3 Usando os Tipos Derivados nos Documentos de Instância

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

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

<?xml version="1.0"?>
<ipo:purchaseOrder
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:ipo="http://www.example.com/IPO"
  orderDate="1999-12-01">

  <shipTo exportCode="1" xsi:type="ipo:UKAddress">
    <name>Helen Zoe</name>
    <street>47 Eden Street</street>
    <city>Cambridge</city>
    <postcode>CB1 1JR</postcode>
  </shipTo>

  <billTo xsi:type="ipo:USAddress">
    <name>Robert Smith</name>
    <street>8 Oak Avenue</street>
    <city>Old Town</city>
    <state>PA</state>
    <zip>95819</zip>
  </billTo>

  <items>
    <item partNum="833-AA">
      <productName>Lapis necklace</productName>
      <quantity>1</quantity>
      <USPrice>99.95</USPrice>
      <ipo:comment>Preciso deste produto agora para as férias!<!/ipo:comment>
      <shipDate>1999-12-05</shipDate>
    </item>
  </items>
</ipo:purchaseOrder>

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.

4.4 Derivando os Tipos Complexos por Restrição

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

<complexType name="RestrictedPurchaseOrderType">
  <complexContent>
    <restriction base="ipo:PurchaseOrderType">
      <sequence>
        <element name="shipTo" type="ipo:Address"/>
        <element name="billTo" type="ipo:Address"/>
        <element ref="ipo:comment" minOccurs="1"/>
        <element name="items"  type="ipo:Items"/>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

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

4.5 Redefinindo Tipos e Grupos

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

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

<schema targetNamespace="http://www.example.com/IPO"
        xmlns="http://www.w3.org/2001/XMLSchema"
        xmlns:ipo="http://www.example.com/IPO">

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

    <!-- redefinition of Address -->
    <complexType name="Address">
      <complexContent>
        <extension base="ipo:Address">
          <sequence>
            <element name="country" type="string"/>
          </sequence>
        </extension>
      </complexContent>
    </complexType>

  </redefine>

  <!-- etc. -->

</schema>

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.

4.6 Grupos de Substituição

<element name="shipComment" type="string"
         substitutionGroup="ipo:comment"/>
<element name="customerComment" type="string"
         substitutionGroup="ipo:comment"/>

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

4.7 Tipos e elementos abstractos

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

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

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

<schema xmlns="http://www.w3.org/2001/XMLSchema"
           targetNamespace="http://cars.example.com/schema"
           xmlns:target="http://cars.example.com/schema">

  <complexType name="Vehicle" abstract="true"/>

  <complexType name="Car">
    <complexContent>
      <extension base="target:Vehicle"/>
    </complexContent>
  </complexType>

  <complexType name="Plane">
    <complexContent>
      <extension base="target:Vehicle"/>
    </complexContent>
  </complexType>

  <element name="transport" type="target:Vehicle"/>
</schema>

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.

4.8 Controlando o Uso e a Criação dos Tipos Derivados

<complexType name="Address" final="restriction">
  <sequence>
    <element name="name"   type="string"/>
    <element name="street" type="string"/>
    <element name="city"   type="string"/>
  </sequence>
</complexType>

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:

<simpleType name="Postcode">
  <restriction base="string">
    <length value="7" fixed="true"/>
  </restriction>
</simpleType>

<simpleType name="UKPostcode">
  <restriction base="ipo:Postcode">
    <pattern value="[A-Z]{2}\d\s\d[A-Z]{2}"/>
  </restriction>
</simpleType>

<simpleType name="UKPostcode">
  <restriction base="ipo:Postcode">
    <pattern value="[A-Z]{2}\d\d[A-Z]{2}"/>
    <!-- illegal attempt to modify facet fixed in base type -->
    <length value="6" fixed="true"/>
  </restriction>
</simpleType>

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:

<complexType name="Address" block="restriction">
  <sequence>
    <element name="name"   type="string"/>
    <element name="street" type="string"/>
    <element name="city"   type="string"/>
  </sequence>
</complexType>

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

5.1 Especificando as Unicidades

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

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

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

<xsd:element name="items" type="Items">
  <xsd:unique name="partNumAndName">
    <xsd:selector xpath="item"/>
    <xsd:field    xpath="@partNum"/>
    <xsd:field    xpath="productName"/>
  </xsd:unique>
</xsd:element>

5.2 Definindo as Teclas-chave e as suas Referências

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

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

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

5.3 Restrições do Esquema XML (x) Atributos ID do XML 1.0

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

5.4 Importando Tipos

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

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

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

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

<complexType name="Analyst">
 <complexContent>
  <extension base="xipo:USAddress">
   <sequence>
    <element name="phone" type="string"/>
    <element name="email" type="string"/>
   </sequence>
  </extension>
 </complexContent>
</complexType>

<r:purchaseReport
  xmlns:r="http://www.example.com/Report"
  period="P3M" periodEnding="1999-12-31">
  <!-- regions and parts elements omitted -->
   <r:analyst>
        <name>Wendy Uhro</name>
        <street>10 Corporate Towers</street>
        <city>San Jose</city>
        <state>CA</state>
        <zip>95113</zip>
        <r:phone>408-271-3366</r:phone>
        <r:email>uhro@example.com</r:email>
   </r:analyst>
</r:purchaseReport>

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.

<schema targetNamespace="http://www.example.com/Currency"
        xmlns:c="http://www.example.com/Currency"
        xmlns="http://www.w3.org/2001/XMLSchema">

  <annotation>
    <documentation xml:lang="en">
      Definição do Tipo de Unidade Monetária em ISO 4217
    </documentation>
  </annotation>

  <complexType name="Currency">
    <simpleContent>
      <extension base="decimal">
        <attribute name="name">
          <simpleType>
            <restriction base="string">

              <enumeration value="AED">
                <annotation>
                  <documentation xml:lang="en">
                    Emirados Árabes Unidos: Dirham (1 Dirham = 100 Fils)
                  </documentation>
                </annotation>
              </enumeration>

              <enumeration value="AFA">
                <annotation>
                  <documentation xml:lang="en">
                    Afganistão: Afghani (1 Afghani = 100 Puls)
                  </documentation>
                </annotation>
              </enumeration>

              <enumeration value="ALL">
                <annotation>
                  <documentation xml:lang="en">
                    Albânia, Lek (1 Lek = 100 Qindarka)
                  </documentation>
                </annotation>
              </enumeration>

              <!-- and other currencies -->

            </restriction>
          </simpleType>
        </attribute>
      </extension>
    </simpleContent>
  </complexType>

</schema>

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

5.5 Qualquer Elemento, Qualquer Atributo

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:

<purchaseReport
  xmlns="http://www.example.com/Report"
  period="P3M" periodEnding="1999-12-31">

  <regions>
    <!-- part sales listed by zip code, data from 4Q99.xml -->
  </regions>

  <parts>
    <!-- part descriptions from 4Q99.xml -->
  </parts>

  <htmlExample>
    <table xmlns="http://www.w3.org/1999/xhtml"
           border="0" width="100%">
      <tr>
        <th align="left">Código Postal</th>
        <th align="left">Parte Número</th>
        <th align="left">Quantidade</th>
      </tr>
      <tr><td>95819</td><td> </td><td> </td></tr>
      <tr><td> </td><td>872-AA</td><td>1</td></tr>
      <tr><td> </td><td>926-AA</td><td>1</td></tr>
      <tr><td> </td><td>833-AA</td><td>1</td></tr>
      <tr><td> </td><td>455-BX</td><td>1</td></tr>
      <tr><td>63143</td><td> </td><td> </td></tr>
      <tr><td> </td><td>455-BX</td><td>4</td></tr>
    </table>
  </htmlExample>

</purchaseReport>

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:

<element name="purchaseReport">
  <complexType>
    <sequence>
      <element name="regions" type="r:RegionsType"/>
      <element name="parts"   type="r:PartsType"/>
      <element name="htmlExample">
        <complexType>
          <sequence>
            <any namespace="http://www.w3.org/1999/xhtml"
                 minOccurs="1" maxOccurs="unbounded"
                 processContents="skip"/>
          </sequence>
        </complexType>
      </element>
    </sequence>
    <attribute name="period"       type="duration"/>
    <attribute name="periodEnding" type="date"/>
  </complexType>
</element>

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.

<xsd:complexType name="text">
  <xsd:complexContent mixed="true">
    <xsd:restriction base="xsd:anyType">
      <xsd:sequence>
        <xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
      </xsd:sequence>
      <xsd:attribute ref="xml:lang"/>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

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

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

<element name="htmlExample">
  <complexType>
    <sequence>
      <any namespace="http://www.w3.org/1999/xhtml"
           minOccurs="1" maxOccurs="unbounded"
           processContents="skip"/>
    </sequence>
    <anyAttribute namespace="http://www.w3.org/1999/xhtml"/>
  </complexType>
</element>

....
  <htmlExample xmlns:h="http://www.w3.org/1999/xhtml"
               h:href="http://www.example.com/reports/4Q99.html">
    <!-- XHTML markup here -->
  </htmlExample>
....

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.

5.6 Localização do Esquema [schemaLocation]

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

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

<purchaseReport
  xmlns="http://www.example.com/Report"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.example.com/Report
  http://www.example.com/Report.xsd"
  period="P3M" periodEnding="1999-12-31">

  <!-- etc. -->

</purchaseReport>

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

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

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

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

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

5.7 Concordância

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.