XPath em Transform da NF-e: cardinalidade e limite do filtro

XPath é um filho de Transform que pode armazenar uma expressão textual. No schema específico da NF-e, a sequência que o contém tem ocorrência de zero a muitas; portanto, ele não é um campo obrigatório 1..1 por transformação.

Caminho desta página: /nfeProc/NFe/ds:Signature/ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform/ds:XPath. O alias ds neste XPath representa o namespace http://www.w3.org/2000/09/xmldsig#; ele permite localizar o elemento, mas não exige esse prefixo na serialização fiscal.

O que a declaração XSD efetivamente permite?

TransformType declara uma sequência com minOccurs="0" e maxOccurs="unbounded", contendo um elemento XPath do tipo string. O elemento dentro da sequência tem ocorrência padrão 1, mas a repetição/opcionalidade da sequência torna a ocorrência efetiva zero a muitas. Ler apenas a linha do elemento perde essa condição.

Isso significa que uma transformação sem XPath pode corresponder à estrutura. Não significa que qualquer expressão é válida, segura ou adequada à NF-e. O tipo string não analisa a sintaxe da linguagem XPath nem seu efeito criptográfico.

Declaração XSD do contexto.

Por que não basta inserir uma expressão de exclusão?

No XMLDSig geral, uma transformação de filtro XPath tem um identificador de algoritmo próprio. O TTransformURI fiscal, porém, só admite enveloped-signature e C14N. O fato de o schema manter o filho XPath não acrescenta o identificador de filtro XPath ao conjunto permitido.

A expressão textual not(ancestor-or-self::ds:Signature) pode lembrar um filtro que exclui assinaturas, mas colocá-la sob um algoritmo enveloped não cria um terceiro método nem substitui o comportamento padronizado desse algoritmo. O perfil do MOC exige as transformações enveloped e C14N; seu exemplo não exige filho XPath.

XMLDSig: processamento e elementos.

Como distinguir expressão, caminho da página e diagnóstico?

O XPath no cabeçalho desta página é um caminho de localização editorial com namespaces associados pelo leitor. O conteúdo de Transform/XPath, quando existe, é parte do XML da assinatura e pertence a outro nível de processamento. Não copie o caminho da página como valor desse filho.

Não há um XML completo de filtro recomendado aqui: uma expressão sintética no contexto errado poderia passar na checagem de string e ensinar um perfil não comprovado. Para investigar um arquivo existente, preserve-o, registre Algorithm, todos os filhos XPath e o comportamento do verificador, sem executar expressões não confiáveis por tentativa. Se o problema nasceu de um modelo genérico, ajuste o gerador para o perfil fiscal e valide em cenário controlado. XSD não comprova assinatura nem autorização.

MOC: perfil de assinatura, pp. 53–56.

Fontes e contexto

Schema específico XMLDSig da NF-e — PL_010f_v1.04 / xmldsig-core-schema_v1.01.xsd; MOC — Visão Geral — 7.0; XML Signature Syntax and Processing — 1.1, Recommendation 11/04/2013.