Publication et découverte

Une machine devrait trouver la représentation avant de commencer à deviner.

Une norme ESFI est publiée comme un contrat que les personnes peuvent lire et que les implémentations peuvent produire. La spécification est la description faisant autorité de ce contrat ; les artefacts lisibles par machine le montrent en usage. Cette page décrit ce qu’un éditeur MPF met en ligne, comment une machine le trouve, et ce que chaque mécanisme établit ou n’établit pas.

Chaque mécanisme est marqué Specification 0.7, Reference implementation ou ESFI practice. Les marqueurs sont expliqués dans la Vue d’ensemble.

Ce qu’un éditeur met en ligne

Comment une machine trouve MPF

Les mécanismes sont organisés du signal le moins coûteux au plus spécifique. Un lecteur peut commencer par n’importe lequel ; ils sont conçus pour être cohérents entre eux.

1. DNS TXT — avant la première requête

ESFI practice

Une seule requête DNS permet à un lecteur de savoir qu’un domaine publie MPF, où se trouve son index et quel est son périmètre par défaut au niveau du site :

_mpf.example.org  TXT  "v=0.7;index=https://example.org/llms.mpf;scope=cite:1,summarize:1,train:0,index:1,relay:0;contact=mailto:web@example.org"

L’enregistrement est assez court pour tenir dans une seule réponse DNS. Le builder ne le crée pas ; l’éditeur l’ajoute à la zone.

2. /.well-known/mpf — la même déclaration via HTTPS

ESFI practice

La même chaîne, servie comme texte brut :

GET /.well-known/mpf
v=0.7;index=https://example.org/llms.mpf;scope=cite:1,summarize:1,train:0,index:1,relay:0;contact=mailto:web@example.org

Servez-la comme fichier statique (par exemple dans public/.well-known/mpf) et assurez-vous que le serveur la renvoie en text/plain. Le builder ne la crée pas. mpf n’est pas encore un well-known URI enregistré ; ESFI utilise ce chemin comme convention.

3. llms.txt — le point d’entrée conventionnel

Specification 0.7

Le builder crée llms.txt s’il n’existe pas, ou remplace sa section MPF tout en préservant tout le reste. La section contient toujours :

MPF: 0.7
MPF-spec: https://docs.esfi.eu/spec/mpf/0.7
MPF-index: /llms.mpf

## Pages
- [Page title](https://example.org/page/index.mpf): summary

MPF-spec apparaît lorsque spec-url est configuré et permet à un lecteur d’atteindre la spécification canonique de la version déclarée sans devoir la deviner. La phrase d’introduction que le builder écrit au-dessus de ces lignes relève de la formulation Reference implementation.

4. llms.mpf — l’index du site

Specification 0.7

llms.mpf est lui-même un document MPF. Son corps énumère chaque page avec index: true, triée par URL MPF, avec son résumé lorsqu’il existe. Son frontmatter déclare une identité fixe (<prefix>:page:llms), content-type: reference et une parité cachée, non HTML, car aucune page humaine ne se trouve derrière lui.

5. La page elle-même

Specification 0.7 pour le chemin et mpf-url ; ESFI practice pour le lien alternate.

Chaque page porte son compagnon au même chemin, avec .mpf à la place de .html :

/about/index.html   →   /about/index.mpf

Chaque fichier MPF s’adresse lui-même via mpf-url et pointe vers sa page humaine via url.

Une page HTML peut également pointer vers son compagnon depuis son <head> :

<link rel="alternate" type="text/mpf" href="/about/index.mpf" title="Machine Page Format">

text/mpf n’est pas un type de média enregistré ; ESFI l’utilise comme convention afin que les lecteurs puissent reconnaître le lien. Le builder ne l’ajoute pas ; le template du site le fait.

Lorsque le site et la page ne sont pas d’accord

L’enregistrement DNS et /.well-known/mpf indiquent les valeurs par défaut du site. Le frontmatter d’une page indique ce qui s’applique à cette page, y compris toute surcharge par page. ESFI practice : sur les sites ESFI, les trois emplacements indiquent les mêmes valeurs au niveau du site, et un lecteur devrait traiter le frontmatter de page comme la déclaration pour cette page. Si une déclaration au niveau du site et une page ne correspondent pas sans surcharge expliquant pourquoi, il s’agit d’une erreur de publication, pas d’un signal invitant à choisir entre les deux.

Canon humain et compagnon machine

La page humaine et son fichier MPF sont deux représentations d’un contenu lié, pas des autorités interchangeables.

• url identifie la page humaine canonique.
• mpf-url identifie la représentation machine.
• content-parity indique comment les deux se rapportent l’une à l’autre.
• source-hash identifie le HTML exact utilisé pour générer le fichier MPF.
• mpf-id identifie le fichier MPF généré lui-même.

Cette séparation permet à une machine de citer ou de traiter la représentation machine sans perdre l’adresse de la source humaine. Pour les traductions, language-variants énumère les adresses MPF attendues du même contenu logique dans les autres langues configurées ; le builder génère ces adresses et ne vérifie pas que les fichiers existent.

Format ouvert, pratique de référence ESFI

MPF est un format ouvert. N’importe qui peut produire et consommer du MPF conforme sans figurer dans un registre, sans s’inscrire et sans utiliser de service ESFI.

Les propres sites d’ESFI constituent une pratique de référence inspectable : ils émettent MPF, publient les index de site et les déclarations de découverte au niveau de la pratique, et exposent l’ensemble pour vérification par rapport à la spécification. Le Registre des implémentations recense les émetteurs dont la sortie a été vérifiée. C’est une preuve d’implémentation, pas une autorisation d’implémenter.

Spécification, implémentation et pratique

• La spécification est le contrat canonique lisible par les personnes pour une version publiée. Une version publiée reste accessible ; les corrections qui ne modifient pas le contrat sont traitées selon la politique de Versionnement.
• L’implémentation de référence transforme la spécification en sortie observable. Ce n’est pas une deuxième spécification. Lorsque la prose et l’implémentation divergent pour une version publiée, elles sont remises en accord ; les lecteurs ne sont pas invités à déduire un troisième contrat à partir d’exemples.
• La pratique décrit la manière dont ESFI déploie MPF au-delà de ce que produit le builder. Elle est documentée afin que d’autres puissent la reproduire. Elle ne devient partie du contrat qu’au travers d’une nouvelle version de la spécification.

Un brouillon, une proposition ou un mécanisme planifié ne fait pas partie de ces conventions tant qu’il n’est pas publié et vérifiable.

Ce que la publication n’implique pas

Publier un champ ou une déclaration ne crée pas un service derrière lui. La provenance, la confiance, le périmètre et les variantes linguistiques sont descriptifs sauf si la spécification définit un comportement supplémentaire. Les mécanismes de découverte aident un lecteur à trouver les déclarations de l’éditeur ; ils ne rendent pas ces déclarations vraies, contraignantes ou appliquées.

La spécification définit le contrat ; l’implémentation de référence le démontre ; la pratique étend la manière dont il est trouvé ; les artefacts publiés rendent les trois inspectables.