Resumo

  • A questão estratégica 560 do W3C continua aberta, chama WebMCP de mudança substantiva da carta e registra como desconhecida a data final do refinamento.
  • O pull request 829, ainda não mesclado, acrescenta integração de agentes no navegador, ferramentas JavaScript imperativas e anotações declarativas de formulários HTML, com WebMCP como entrega provisória.
  • O patch não atualiza os grupos citados na seção de coordenação, embora a questão estratégica solicite participação de HTML, ARIA, TAG, SING e Privacy.
  • WebKit se opõe, Mozilla mantém posição neutra, APA não apoia o relatório atual e a modelagem de ameaças segue em andamento. Nenhum desses registros decide a carta.
  • Antes da análise pelo Advisory Committee, uma matriz de escopo e responsáveis deveria separar propriedade, dependência, consulta e revisão horizontal sem criar vetos automáticos.

O estado é de proposta, mas a mudança é institucional

A cronologia impede conclusões apressadas. A questão 560 foi aberta em 9 de junho de 2026, permanece aberta e não tem previsão para o encerramento do refinamento. O pull request 829 também está aberto, não foi mesclado e possui um único commit principal, da mesma data. Os documentos sustentam a expressão “escopo proposto”. Não sustentam que a carta foi aprovada, que WebMCP foi adotado ou que já existe um padrão de navegador em implantação.

O conteúdo proposto, porém, desloca a fronteira do mandato. A carta vigente do Web Machine Learning Working Group se concentra em inferência: WebNN como API de baixo nível, acesso a aceleradores da plataforma e possível carregamento de modelos. O patch muda “Web API” para o plural e acrescenta a integração nativa de agentes de IA no navegador.

Uma trilha é imperativa. Uma aplicação poderia registrar, atualizar e remover funções JavaScript como ferramentas estruturadas, com descrições e entradas organizadas por esquemas. A outra é declarativa. Elementos HTML, sobretudo formulários, receberiam anotações para que agentes descubram ações legíveis por máquina. O navegador faria mediação, aplicaria limites de mesma origem e autorização do usuário e permitiria o acionamento direto de recursos da página.

Assim, a proposta junta execução no navegador, autoria HTML, experiência de acessibilidade e limites de confiança do agente. “Tentative” é uma ressalva importante: ainda seriam necessários progresso de incubação, interesse de vários implementadores e consenso do Working Group antes da adoção como trabalho em trilha de Recommendation. A ressalva preserva etapas; não reduz a ampliação de autoridade a uma edição de palavras.

A lista nominal continua presa ao mandato anterior

O patch altera o escopo e as entregas provisórias, mas não a seção de coordenação técnica adicional. O rascunho público continua citando Web Machine Learning Community Group, GPU for the Web Working Group, WebAssembly Community Group, WebRTC Working Group e Technical Architecture Group. A lista externa traz ECMA TC39.

Também existe uma obrigação geral de revisão horizontal em acessibilidade, internacionalização, privacidade, segurança e arquitetura. Ela importa e impede a alegação de que a proposta ignora essas áreas. Entretanto, revisão horizontal e dependência nominada respondem a perguntas diferentes.

O revisor horizontal testa um texto contra requisitos transversais. Uma relação de dependência indica qual outro órgão controla uma camada, que entrega pode afetá-la e como as mudanças serão comunicadas. Proprietário de especificação, coeditor, grupo consultado e revisor não têm a mesma autoridade. Quando uma proposta mapeia ações diretamente em formulários HTML e levanta dúvidas sobre ARIA ou a árvore de acessibilidade, essas funções precisam ser distinguíveis.

A própria questão 560 já identifica a rede relevante: HTML, ARIA, TAG, Security Interest Group e participantes de Privacy. As conversas públicas confirmam que a coordenação está ocorrendo. A lacuna é documental: o patch que pede o novo mandato ainda não converte essa rede em dependências e canais atribuíveis.

Quatro opiniões públicas não formam uma votação

O registro do WebKit é contrário. A análise afirma que a proposta pode criar uma interface paralela para agentes, que algumas lacunas deveriam ser resolvidas nas semânticas compartilhadas de HTML e acessibilidade e que o foro de Machine Learning não é o local correto para decidir a evolução dessas camadas. Um representante da Apple disse depois, no pull request da carta, que esperaria apresentar uma objeção formal caso o patch fosse mesclado, deixando aberta a possibilidade de outro foro no W3C. É uma objeção relevante, mas não é veto nem decisão institucional.

Mozilla registra neutralidade. Sua avaliação vê utilidade possível, mas mantém dúvidas sobre riscos, terminologia, limites do ecossistema e relação entre os modelos imperativo e declarativo. As discussões de fim de agosto continuam sem fechar a forma da API. Neutralidade não é apoio de implementação e tampouco oposição.

O comentário de 27 de agosto do Accessible Platform Architectures Working Group tem outro foco. Os participantes reconhecem potencial experimental, inclusive para certas necessidades cognitivas, mas não apoiam o relatório atual do Community Group. Perguntam como a pessoa descobre, examina, aprova, cancela e desfaz ações do agente; separam os dados de WebMCP da árvore de acessibilidade e alertam para uma divergência entre o que humanos e agentes conseguem fazer. A abordagem declarativa parece um ponto de partida melhor, mas continua experimental.

O Security Interest Group está em uma etapa diferente. As atas de julho discutem limites entre site, navegador, agente e usuário, conteúdo das ferramentas, exposição entre origens, visibilidade e duração. Elas registram um modelo de ameaças iterativo, não uma aprovação de segurança nem uma rejeição.

Oposição, neutralidade, não apoio condicionado e análise em curso são estados distintos. Somá-los como se fossem uma pesquisa de opinião apagaria justamente as diferenças que o refinamento da carta precisa resolver.

Dependência e disposição fazem parte do processo

O Processo do W3C exige que uma carta defina escopo e entregas e identifique dependências de e para outros grupos. Quando terceiros dependem das entregas, a carta também deve identificar mecanismos de comunicação. Antes da análise pelo Advisory Committee, a revisão ampla deve ser concluída; questões contra o rascunho precisam de tratamento formal, resoluções rastreadas em uma disposição de comentários e objeções persistentes destacadas.

Isso não transforma todo grupo afetado em coproprietário, nem dá a revisores horizontais poder unilateral de bloqueio. Uma matriz não deve funcionar como cadastro de vetos. Sua função é esclarecer quem controla a camada, por onde uma incompatibilidade é levada e qual autoridade responde pela decisão.

Essa precisão pesa ainda mais diante de um novo escopo. Uma nova entrega em trilha de Recommendation fora do escopo de entregas existentes é uma mudança maior de carta e exige análise do Advisory Committee. Até que isso ocorra, a carta ativa, válida até 30 de abril de 2027, continua sendo o mandato aplicável e permanece centrada em aprendizagem de máquina.

Uma matriz que não antecipa a decisão sobre o foro

O processo poderia publicar uma matriz versionada ao lado do diff. Cada linha conteria a revisão da carta e o commit imutável; a superfície normativa proposta; a camada afetada; a autoridade pretendida para o Working Group; e o órgão dependente, mantenedor ou revisor. O papel seria classificado como coproprietário, dependência, liaison, consulta ou revisão horizontal. A linha ainda traria o canal público, o pedido e a resposta de revisão, a objeção pendente e sua justificativa, o gatilho de adoção ou transferência, o estado de maturidade e patentes, o próximo responsável e a data de verificação.

Na linha dos formulários declarativos, seria possível identificar a camada HTML e seus mantenedores sem presumir que todos coeditam WebMCP. Na acessibilidade, a propriedade de ARIA ou da árvore acessível ficaria separada da função horizontal de APA. Segurança receberia “modelagem de ameaças em andamento”, e não um selo verde. Posições de navegadores permaneceriam separadas do consenso do grupo e da aprovação do W3C.

A matriz não determina se o trabalho pertence a Web Machine Learning, a um grupo novo, a foros coordenados ou apenas ao Community Group. Ela evita que a escolha institucional fique escondida na palavra genérica “coordenação”.

A disciplina de especificação mínima de Heng Lu define o limite. O registro comum deve ter apenas as junções necessárias à coordenação, enquanto decisões futuras ficam com os atores que possuem cada camada. O objetivo não é centralizar toda a Web de agentes, mas evitar que uma carta herde autoridade sobre camadas vizinhas pelo silêncio.

O limite das conclusões

A ausência de um grupo na lista pública não prova que não houve reuniões ou contatos informais. A oposição da Apple não é uma rejeição do W3C. A neutralidade da Mozilla não estabelece consenso entre implementadores. O comentário de APA não elimina todos os desenhos possíveis, e as atas de segurança não provam que WebMCP seja inseguro.

Também não há prova de adoção, interoperabilidade ou implantação. WebMCP permanece um relatório de Community Group, e o patch da carta continua aberto. Incubação, item provisório de carta, adoção pelo Working Group, Working Draft e Recommendation são estados separados.

O fato de governança que resiste à verificação é mais estreito: uma proposta aberta daria a um Working Group espaço para explorar superfícies ligadas a HTML e agentes no navegador, enquanto a lista nominal de coordenação permanece alinhada ao antigo mandato. A revisão pública tornou atores e dúvidas visíveis. Falta ligá-los a funções, canais e disposições antes que escopo se torne autoridade.

Fontes

  1. W3C Strategy — questão 560 sobre a carta Web Machine Learning
  2. W3C charter-drafts — pull request 829
  3. W3C charter-drafts — commit do escopo WebMCP
  4. W3C — rascunho público da carta Web Machine Learning
  5. Processo do W3C — conteúdo de uma carta
  6. W3C — carta ativa do Web Machine Learning
  7. WebKit — posição sobre WebMCP
  8. Mozilla — posição sobre WebMCP
  9. WebMCP issue 65 — revisão de acessibilidade de APA
  10. W3C Security Interest Group — atas do modelo de ameaças de WebMCP
  11. Web Machine Learning Community Group — relatório WebMCP
  12. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption