Summary

  • Em 14 de outubro de 2003, o W3C publicou o XForms 1.0 como Recomendação. A arquitetura separava modelo, dados de instância em XML e interface; vínculos ligavam cada controle visível aos dados correspondentes.
  • No exemplo de pagamento da própria especificação, número e vencimento do cartão só são pertinentes na opção de crédito. A propriedade relevant orienta os controles disponíveis e retira da submissão os nós que ficaram fora daquela escolha.

Você entrega dinheiro ao caixa. Ele conta as notas, sorri e pede o número do cartão. Por quê? Porque o formulário tem um quadrinho para preenchê-lo. Há uma forma especial de teimosia em transformar toda caixa desenhada numa obrigação do cliente. O XForms 1.0, Recomendação do W3C datada de 14 de outubro de 2003, tratou esse problema como uma questão de arquitetura: a regra que governa uma pergunta precisa acompanhar os dados, e o programa precisa executá-la.

A proposta distinguia três partes. O modelo descrevia a estrutura e as regras do formulário. A instância guardava os valores num documento XML que ia sendo preenchido. A interface mostrava os controles usados por uma pessoa. Um vínculo ref ligava um controle ao nó da instância que ele deveria alterar. Assim, o desenho na tela deixava de ser o único lugar onde o significado do formulário morava.

O exemplo apresentado pelo W3C é deliberadamente comum: escolher dinheiro ou crédito e, no segundo caso, informar número e vencimento. O elemento instance começa com um esqueleto XML para método, número e validade; submission aponta o destino. Na interface, select1 oferece a escolha, input recolhe os dados de cartão e cada controle carrega seu label. Conforme o usuário responde, a instância muda. Quando chega a hora do envio, o processador serializa seu conteúdo em XML.

select1 expressava a intenção de escolher uma opção sem impor o mesmo botão a todo dispositivo. Uma tela e uma interface por voz poderiam apresentar a escolha de modos diferentes. A ligação aos dados mantinha a identidade do que era coletado. Essa liberdade de apresentação exigia disciplina do autor: cada controle precisava apontar para o nó certo, como uma etiqueta presa à pasta certa.

O teste de boas maneiras acontece na opção em dinheiro. No exemplo, os vínculos dos campos de número e vencimento contêm uma expressão relevant que verifica se o método vale cc, o valor usado para crédito. Os mesmos vínculos declaram os campos obrigatórios quando essa opção se aplica e associam tipos aos valores. O número usa um padrão de 14 a 18 dígitos; o vencimento, xsd:gYearMonth. O programa avalia essas regras quando o método muda. O caixa imaginário para de procurar um cartão que não existe na transação.

A definição de relevant na Recomendação chega até o arquivo que sai da máquina. Um nó considerado irrelevante fica fora da serialização para submissão. Seu controle se torna indisponível, deixa a ordem de navegação e não recebe foco. Quando o cliente escolhe crédito, os campos entram no caminho ativo e seus valores podem ser exigidos. Quando escolhe dinheiro, o número do cartão sai também do XML enviado.

Esse último movimento é a diferença entre uma cortina e uma decisão. Esconder uma caixa na tela pode deixar um valor velho nos dados. O XForms fazia a condição alcançar a interface e a instância: o modelo define a pertinência, o processador aplica a regra, o usuário vê o resultado e o documento transmitido carrega a mesma escolha. Para uma simples compra, é uma cadeia de responsabilidades bastante adulta.

No anúncio de 2003, o W3C apresentou essa divisão como separação entre finalidade, apresentação e resultado. A finalidade da ficha é registrar o método de pagamento; a apresentação encontra o aparelho; o resultado é a instância XML. A cena do dinheiro mostra o que a frase quer dizer no balcão: a pergunta do cartão sabe quando se despedir.