Pular para conteúdo
Nesta página

Legible e propostas independentes

Precisão normativa e pluralidade de propostas

Uma especificação precisa fixar regras para que implementações independentes interoperem, sem tornar suas escolhas a única resposta possível ao problema. Os mantenedores decidem o que incorporar à edição que publicam, enquanto outros participantes podem desenvolver propostas com decisões e manutenção próprias.

Uma alteração recusada pode permanecer disponível, ser discutida em outro contexto ou dar origem a outra especificação. Preservar essas possibilidades é coerente com a tese que orienta o Legible.

Nomes de propostas derivadas

Use um nome distinto e versões próprias. Legible Aurora seria, por exemplo, um nome para uma proposta independente; Legible Aurora 1.0, uma edição dessa proposta. O número não a colocaria numa sequência oficial de sucessão do Legible.

Os mantenedores permitem nomes compostos com Legible dentro dos direitos que controlam. Identifique autores, mantenedores, edição e endereço, preserve a atribuição dos materiais reutilizados e explique as diferenças. O nome comum ajuda a reconhecer a origem; a identificação explícita da proposta evita confusão sobre quem a mantém.

Essa permissão não concede direitos de terceiros nem autoriza apresentar outra proposta como publicação ou serviço destes mantenedores. Consulte as licenças e notas de publicação.

Identificação e conformidade

O nome identifica a proposta; a edição fixa o contrato; os testes mostram quais operações interoperam. Uma numeração maior não demonstra qualidade ou sucessão. Para distinguir artefatos com nomes semelhantes, indique também autoria, URI e hash da especificação.

Ao declarar conformidade, informe a especificação, a edição e os perfis implementados. Mantenha visível o estado de rascunho. “Compatível com Legible”, sem esses detalhes, não informa qual contrato foi testado.

Espelhos, implementações e especificações independentes

Um espelho redistribui o mesmo texto normativo. Um fork de implementação pode mudar o código e continuar conforme à mesma edição. Uma especificação independente pode mudar o contrato e precisa explicar onde diverge.

A pasta .legible é a convenção de armazenamento desta especificação. Se houver contratos incompatíveis, distinga schemas, namespaces de assinatura e armazenamento onde necessário. Declarações diferentes não devem parecer equivalentes. Mudar apenas o nome do projeto não exige alterar os bytes dos registros que continuam conformes.

Origem ou nome em comum não criam manutenção conjunta nem endosso. Cada publicação identifica seus responsáveis. Este site não precisa hospedar, catalogar ou moderar propostas independentes.

Como publicar uma proposta independente

  1. Escolha no repositório do protocolo a edição e os materiais que vai reutilizar. Confira licenças, atribuição e identificação das mudanças.
  2. Defina nome, edição, mantenedores e endereço estável. Pode ser um repositório ou site estático; domínio próprio é opcional.
  3. Explique as diferenças e os contratos preservados. Use identificadores distintos onde houver incompatibilidade e publique critérios de conformidade.
  4. Inclua exemplos e testes reproduzíveis com chaves fictícias, indicando o que foi verificado e os limites conhecidos.
  5. Quando corresponder à origem, use uma descrição como “proposta independente derivada de The Legible Protocol, rascunho 0.4”, identificando a edição reutilizada.

Essa descrição ajuda leitores a encontrar e comparar propostas pelos canais comuns de publicação e busca. Não há cadastro do protocolo que garanta descoberta ou posição em buscadores. Trace e Nod são opcionais e não substituem a atribuição exigida pelas licenças.

Entenda a arquitetura · Leia a especificação

Ler esta página em Markdown