1.1 Terminologia

Esta especificação utiliza a terminologia do Infoset XML (ver [InfoSet XML]) ao discutir o conteúdo e a extrutura XML. Esta é apenas uma convenção para uma especificação clara do comportamento XOP.

Os seguintes termos são utilizados nesta especificação:

• Infoset XML Original - Um Infoset XML a ser optimizado.
• Conteúdo Optimizado - Conteúdo que tenha sido removido do Infoset XML.
• Infoset XOP - O Infoset Original com qualquer Conteúdo Optimizado, removido e substituído por xop:Inclui itens com informações referentes ao seus elementos.
• Documento XOP - A serialização do Infoset XOP, utilizando qualquer versão do nível de recomendação do XML.
• Pasta XOP - Uma pasta contendo o Documento XOP e/ou qualquer outro Documento Optimizado. Como um todo, a Pasta XOP é uma serialização alternativa do Infoset Original.
• Infoset XML Reconstituído - Um Infoset XML que tenha sido construído a partir de uma pasta XOP.

1.2 Exemplos

O exemplo 1 exibe um Infoset XML antes do processamento XOP. O exemplo 2 exibe o mesmo Infoset, serializado através da utilização do formato XOP numa MIME Multipart/Pasta Associada. O conteúdo codificado da base-binária-64 m:photo e os elementos m:sig foram substituídos por um elemento xop:Include, enquanto que os octetos binários foram serializados em partições MIME separadas. Note-se no entanto que esses exemplos se servem de [Atribuíndo Tipos de Media aos Dados Binários em XML] para identificar o tipo de media do conteúdo de m:photo e dos elementos m:sig . Note também que os dados da amostra codificada numa base-binária-64 são mais pequenos do que aquilo que se seria de esperar e que os octetos binários não são exibidos; na prática, a forma optimizada é provávelmente muito mais pequena do que a sua forma original.

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo
  xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
      <m:sig
  xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

Versão MIME: 1.0
Tipo de conteúdo: Multipart/Related;boundary=MIME_boundary (limite);
    type="application/xop+xml";
    start="<mymessage.xml@example.org>";
    startinfo="application/soap+xml; action=\"ProcessData\""
Descrição do Conteúdo: Uma mensagem SOAP com o meu...

--MIME_boundary (limite)
Tipo de conteúdo: applicação/xop+xml;
    charset=UTF-8;
    tipo="applicação/soap+xml;action=\"ProcessData\""
Codificação da transferência do conteúdo:8bit
ID do Conteúdo: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo
  xmlmime:contentType='image/png'><xop:Include
    xmlns:xop='http://www.w3.org/2004/08/xop/include'
    href='cid:http://example.org/me.png'/></m:photo>
      <m:sig
  xmlmime:contentType='application/pkcs7-signature'><xop:Include
    xmlns:xop='http://www.w3.org/2004/08/xop/include'
    href='cid:http://example.org/my.hsh'/>>/m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary (limite)
Tipo de conteúdo:image/png
Codificação da transferência do conteúdo:binária
ID do Conteúdo:<http://example.org/me.png>

// octetos binários para png

--MIME_boundary (limite)
Tipo de conteúdo:application/pkcs7-signature
Codificação da transferência do conteúdo:binária
ID do Conteúdo:<http://example.org/my.hsh>

// octetos binários para a assinatura

--MIME_boundary--

O exemplo 3 exibe um Infoset XML antes do processamento XOP. O exemplo 4 exibe o mesmo Infoset, serializado através da utilização do formato XOP numa MIME Multipart/Pasta Associada. . O conteúdo codificado da base-binária-64 dos elementos m:photo e m:sig foram substituídos por um elemento xop:Include, enquanto que os octetos binários foram serializados em partições MIME separadas. Note-se também aqui que a amostra dos dados codificados em base-binária-64 é mais pequena do que aquilo que seria de esperar e que os octetos binários não são exibidos;na prática, é provável que a forma optimizada seja muito mais pequena do que a forma original.

<m:data xmlns:m='http://example.org/stuff'>
  <m:photo>/aWKKapGGyQ=</m:photo>
  <m:sig>Faa7vROi2VQ=</m:sig>
</m:data>

Versão MIME:1.0
Tipo de conteúdo: Multipart/Related;boundary=MIME_boundary (limite);
    type="application/xop+xml" (tipo);
    start=" (início)<mymessage.xml@example.org>";
    start-info="text/xml"
Descrição do Conteúdo: Um documento XML com o meu...
--MIME_boundary (limite)
Tipo de conteúdo: application/xop+xml (aplicação);
    charset=UTF-8;
    type="text/xml"
Codificação da transferência do conteúdo: 8bit
ID do Conteúdo: <mymessage.xml@example.org>
<m:data xmlns:m='http://example.org/stuff'>
  <m:photo><xop:Include
  xmlns:xop='http://www.w3.org/2004/08/xop/include'
  href='cid:http://example.org/me.png'/></m:photo>
  <m:sig><xop:Include
  xmlns:xop='http://www.w3.org/2004/08/xop/include'
  href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>
--MIME_boundary (limite)
Tipo de conteúdo: image/png
Codificação da transferência do conteúdo: binária
ID do Conteúdo: <http://example.org/me.png>
// octetos binários para png
--MIME_boundary (limite)
Tipo de conteúdo:application/pkcs7-signature
Codificação da transferência do conteúdo: binária
ID do Conteúdo:<http://example.org/my.hsh>
// octetos binários para a assinatura
--MIME_boundary--

1.3 Notas referentes às Convenções

As palavras-chave "MUST" (tem de), "MUST NOT" (não é obrigatório), "REQUIRED" (requerido), "SHALL" (deve), "SHALL NOT" (não deve), "SHOULD" (deveria), "SHOULD NOT" (não deveria), "RECOMMENDED" (recomendado), "MAY" (pode) e "OPTIONAL" (opcional), deverão ser interpretadas neste documento de acordo com os parâmetros descritos no RFC 2119 [RFC 2119].

Esta especificação utiliza um número de prefixos de espaços nominais por toda a sua área; eles serão listados mais abaixo. Note-se que a escolha do prefixo do espaço nominal é arbitrário e não possui qualquer significado semântico.

2.1 xop:Include - item com informação referente aos elementos

O item com a informação referente aos elementos (xop:Include ), contém:

• Um [nome local] do tópico Include.
• Um [espaço nominal nome] do URI "http://www.w3.org/2004/08/xop/include".
• Um ou mais itens com informação referente aos atributos, retirados de entre todas as suas propriedades, como se segue:
  • Um item de informação href obrigatório, com informações referentes aos atributos (ver 2.2 Item de informação –href- referente aos atributos).
  • Itens de informação qualificada referente aos atributos e qualidades do zero ou de outros espaços nominais. Qualquer um desses itens de informação referente aos atributos não terá obrigatóriamente de ter um [espaço-nominal nome] do "http://www.w3.org/2004/08/xop/include", não terá de alterar a semântica do processamento do item xop:Include, com a informação referente aos elementos e DEVERÁ ser ignorado, caso não seja reconhecido.
• Itens de informação qualificada dos elementos referente ao zero ou a outros espaços-nominais na sua propriedade [derivada]. Qualquer destes itens com a informação referente aos elementosNÃO DEVERÁ obrigatóriamente possuir um [espaço-nominal nome] do URI "http://www.w3.org/2004/08/xop/include", NÃO DEVERÁ alterar a semântica do processamento do item com a informação referente aos elementos xop:Include e DEVERÁ ser ignorado, caso não seja reconhecido.

2.2 Item com a informação referente aos atributos e qualidades href

O item com a informação referente aos atributos href possui:

• Um [nome local] do href.
• Um [espaço-nominal nome] vazio.
• Um [valor normalizado], o qual é na realidade a representação do URI (ver [RFC 2396] como o emendado pelo [RFC 2732]), referenciando a parte da pasta que contém os dados logicamente incluídos pelo [owner element] (por exemplo, o item de informação xop:Include ,referente aos elementos). O [valor normalizado] TEM DE SER um URI validado pelo CID: Esquema URI (ver [RFC 2392]). Acrescentando mais alguns factos, o [valor normalizado] tem de ser uma forma lexical válida do Esquema XML xs: qualquer dado do tipo URI (ver [Esquema XML, Parte 2: Tipos de dados, 2ª. Edição]3.2.17 qualquer URI).
• Um elemento do tipo [owner element] que seja um item de informaçãoxop:Include referente aos elementos, contendo o item de informação referente aos atributos ou qualidades.

3.1 Criando as pastas XOP

Para criar uma Pasta XOP a partir de um Infoset XML Original:

1. Assegure-se de que o Infoset XML Original não contém nenhum item de informação referente aos elementos contendo o [espaço-nominal nome] do URL "http://www.w3.org/2004/08/xop/include" e o [nome local] do xop:code>Include. De acordo com o qua já foi aqui discutido no tópico 2 Arquitectura do Infoset XOP, os Infosets XML que contenham tais itens de informação referentes aos elementos ,não poderão ser representados através da utilização do XOP.
2. Crie uma pasta vazia.
3. Identifique, dentro do Infoset XML Original, os itens de informação referentes aos elementos a serme optiimizados. Para serem optimizados, os caractéres compreendendo a derivada original do item com a informação referente ao elemento DEVERÁ estar na forma canónica do código xs:base-binária-64 (ver [Esquema XML, Parte 2: Tipos de dados, 2ª. Edição]3.2.16 base-binária-64) e NÃO É OBRIGATÓRIO conter quaisquer espaços em branco, precedendo em linha com ou a seguir ao conteúdo que se distinga desses espaços em branco.
4. Crie um Infoset XOP, o qual seja uma cópia do Infoset XML Original, mas com a derivada ([children]) de cada item com informação referente aos elementos, identificado na etapa anterior e substituída por um elemento do tipo xop:Incluir (ver 2.1 xop:Incluir item com informações referentes aos elementos), o qual é construído da seguinte forma:
   1. Transforma os caractéres que foram substituídos em dados binários, através do seu processamento em dados codificados para a base-binária-64.
   2. Serializa os dados binários para uma nova partição da pasta, com meta-dados apropriados e correspondendo ao [valor normalizado] do item com a informação referente aos atributos do tipo href do tópico xop:Incluir informações referentes aos elementos (ver 2.2 Item com informações referentes aos atributos href).
   3. Se o item com a informação referente aos elementos a serem optimizados (por exemplo, os dados ancestrais do mais recentemente inserido xop:Inclui item com informações referentes aos elementos) contiver um item com informações referentes ao atributo do tipo xmlmime:Tipo de conteúdo, o seu valor DEVERÁ refelectir-se adequadamente nos meta-dados destinados a essa parte.
5. Serializa o Infoset XOP daí resultante numa pasta, usando qualquer versão do nível de recomendação W3C para o XML (ex: [Linguagem Extensível do Markup (XML) 1.0 (3ª. Edição)], [Linguagem Extensível do Markup (XML) 1.1]) e identifica-o it como parte da raíz, da acordo com a convenção do mecanismo de empacotamento, etiquetando-o com o tipo de meio da aplicação/xop+xml (application/xop+xmlmedia type), como descrito no tópico 5 Identicando os Documentos XOP.

Outras partes PODERÃO ser adicionadas à pasta, a fim de satisfazer os requerimentos específicos da aplicação. Outros conteúdos específicos PODERÃO ser reflectidos no empacotamento dos meta-dados, de acordo segundo o mais indicado.

Se o conteúdo não puder ser codificado com êxito para a pasta XOP, as implementações dever-se-ão comportar como se essa parcela do Infoset XML Original não tivesse sido nomeada para a optimização em causa.

3.2 Interpretando as pastas XOP

Esta secção especifica os meios pelos quais o Infoset XML Original poderá ser reconstruído, a partir de uma pasta XOP que tenha sido preparada de acordo com as regras definidas no tópico 3.1 Criando as Pastas XOP.

Nota: convenções ou mecanismos do relatório dos erros a serem usados no processo de empacotamento de pastas, as quais se pensava falsamente tratarem de Pastas XOP, estão para além da área desta especificação.

Para criar um Infoset XML Reconstituído XML a partir de uma Pasta XOP:

1. Construa um Infoset XML, considerando e analisando gramaticalmente a parte da raíz pertencente à Pasta como um documento XML. O documento DEVERÁ ser analisado de acordo com o nível da Recomendação XML, identificada na declaração XML do mesmo documento. Se não existir nenhuma declaração XML presente, então o documento DEVERÁ ser conjunturalmente analisado segundo o descrito na [Linguagem de Markup extensível (XML) 1.0 (3ª. Edição)].
2. Utilizando esse Infoset XML para cada item E, o qual contém informações referentes aos elementos e ainda, na qualidade de elemento único da sua propriedade de derivada ([children]), um tópico com informações referentes aos elementos do tipo xop:Include,(como o definido em 2.1 xop:Inclui um item com informações referentes aos elementos):
   1. Localiza a parte da pasta que corresponde ao URI do item com a informação referente aos atributos href contido no tópico com a informação referente aos elementos xop:Include (i.e., correspondendo ao URI codificado no [valor normalizado] do item de informação referente aos atributos.
   2. Substitui o item xop:Incluircode> informações referentes aos elementos</<em>, o qual aparece na propriedade derivada de E, contendo itens de carácter informativo e representando a forma canónica da codificação em base-binária-64 do corpo da entidade da fracção identificada pertencente à pasta (isto significa, ela substitui efectivamente o item com a informação referente aos elementos xop:Include, com os dados reconstruídos a partir dessa fracção da pasta.

4.1 MIME Multipart/Pastas XOP Associadas

Esta secção descreve a forma como o empacotamento das Pastas MIME/Associadas (como especificado em [RFC 2387]) é usado com o XOP.

A parte da raíz MIME é a parte da raíz pertencente à Pasta XOP e DEVERÁ ser uma serialização do uso do Infoset XOP que utilize qualquer nível de recomendação do W3C referente às versões XML (exemplo: [Linguagem Markup Extensível (XML) 1.0 (3ª. Edição)], [Linguagem Markup Extensível (XML) 1.1]) e DEVE ser identificada com o tipo de meio da “aplicação/xop+xml” (como é definido mais abaixo). O parâmetro contendo a informação inicial referente ao tipo de meio utilizado na pasta DEVERÁ conter o tipo de conteúdo associado ao conteúdo da serialização XML. (exemplo: ela conterá o mesmo valor que o parâmetro referente ao tipo da parte da raíz).

À excepção do objectivo de determinar a parte MIME na raíz, como o especificado em [RFC 2387], a ordenação das partes MIME não têm obrigatóriamente de ser consideradas como significantes no processamento XOP ou na construção do Infoset XOP.

A parte correspondente aos meta-dados é reflectida em campos do encabeçamento do MIME. Especificamente falando, o URI utilizado no valor correspondente a um item com informações referentes aos atributosattribute href, num item contendo as informações relativas aos elementos do tipo xop:Include, contém a URI que utiliza o esquema “cid:” (ver [RFC 2392]), de maneira que a parte MIME e ele correspondente DEVERÁ conter um campo destinado ao cabeçalho com a ID do Conteúdo (Content-ID)(ver [RFC 2387]), com o valor de campo correspondente.

Além disso, se um item com as informações referentes ao atributo, do tipo xmlmime:Tipo de conteúdo ,fôr encontrado (como é descrito em 3 Modelo de Processamento XOP), ele deve-se reflectir no campo dos valores relativo ao cabeçalho do Tipo de Conteúdo MIME.

5.1 Registro

Nome do tipo de meios MIME:

aplicação

Nome do sub-tipo MIME:

xop+xml

Parâmetros requeridos:

tipo

Este parâmetro transporta o tipo de conteúdo associado à serialização do Infoset XML, incluindo os parâmtros da forma mais apropriada.

Parâmetros opcionais:

charset

Este parâmetro contém semânticas idênticas às dos parâmetros dos “charsets" do tipo de meio “aplicação/xml”, como o especificado em RFC 3023 [RFC3023].

Codificando as considerações:

Idêntico ao sucedido nas "aplicações/xml”, como descrito em RFC 3023 [RFC3023], secção 3.2.

Considerações relacionadas com a segurança

Em adição às considerações específicas referentes à aplicação, o xop contém as mesmas considerações relacionadas com a segurança que as descritas em RFC3023 [RFC3023], na secção 10.

Considerações relacionadas com a Inter-operacionabilidade:

Não existe conhecimento de quaisquer acções de inter-operacionabilidade.

Especificações publicadas:

Este documento

Aplicações que usam este tipo de meio:

Até à data, não existe qualquer conhecimento de aplicações que usem este tipo de meio.

Informações adicionais:

Extensão do ficheiro:

XOP

Identificadores dos segmentos:

Idênticos aos dos identificadores da "aplicação/xml”, como descrito em RFC 3023 [RFC3023], na secção 5.

Base URI:

Como o especificado no RFC 3023 [RFC3023], na secção 6.

Código do Tipo de Ficheiro Macintosh:

TEXT

Nomes e endereços electrónicos a contactar, para mais informações:

Mark Nottingham, da BEA <mnot@pobox.com>

Uso previsto:

COMUM

Autor/Controle das alterações verificadas:

A especificação XOP é o produto de trabalho do Consórcio da World Wide WebGrupo de Trabalho responsável pelo Protocolo. O W3C detém o absoluto controle sobre qualquer alteração a verificar nesta especificação.

6.1 Integridade das pastas XOP

A integridade dos Infosets optimizados através do uso do XOP poderá necessitar de ser assegurada. Dado que as pastas XOP podem ser transformadas para recuperar tais Infosets (ver 3.2 Interpretando as Pastas XOP), as técnicas de Assinatura Digital XML existentes poderão ser usadas para os proteger. Note contudo, que uma assinatura sobre o Infoset não o protegerá necessáriamente contra modificações dos outros aspectos do empacotamento XOP; por exemplo, uma verificação da assinatura do Infoset não o poderá proteger contra uma eventual reorganização das partes que não estejam relacionadas com a raíz.

Futuramente, os algorítmos de transformação a serem utilizado conjuntamente com as Assinaturas XML, poderiam fornecer um modelo de processamento mais eficiente, especialmente nos pontos onde os octectos, na sua forma mais “crua”, tenham de ser directamente “digeridos” (trabalhados).

6.2 Confidência das pastas XOP

A confidencialidade das Pastas XOP poderá necessitar de ser assegurada. Dado que estas Pastas podem ser transformadas em Infosets XML, as técnicas de codificação XML existentes (ver [XML Codificando a Sintaxe e o Processamento]) podem ser usadas, a fim de proteger tais Pastas. Qualquer parte da referida Pasta poderá ser codificada, quer inclua caractéres na base-binária-64, quer não. O item com a informação dos elementos CipherData,resultante dessa codificação, poderá ser optimizado, dado que o seu conteúdo foi definido com caractéres na base-binária-64.

Futuramente, um algorítmo de transformação utilizado conjuntamente na codificação XML poderia fornecer um modelo de processamento mais eficiente, especialmente nos pontos onde os octetos são directamente codificados.