Je confirme que toutes mes notes (FAM INDI SOUR) sont déplacées, seul celle du head ne l'est pas 
ça ne me pose pas de problème mais le fait est que ce ne sont pas des notes partagées mais bien individuels et donc peut être que ce n'est pas utile.
J'ai vérifié le code, c'est spécifique à Heredis, il doit y avoir une version de Heredis qui provoque des problèmes avec ses notes embarquées.
Pas plus d'explications pour le moment, faut que j'en parle avec Frédéric pour savoir exactement pourquoi cela a été fait.
Je ne sais peut être pas bien chercher mais je ne vois nul part dans la norme une contre indication à cet usage qui serait très limitant quand à l'utilisation de cette balise.
Quand l'heure d'un acte est indiquée je la reporte, et ce serait dommage d'avoir FAM:MARR:NOTE 11:00 au lieu de FAM:MARR:DATE:TIME 11:00.
En fait, c'est expliqué en page 9 de la spécification :
They also allow the use of different or new fields to be included in the GEDCOM data without
introducing incompatibility, because the receiving system will ignore data which it does not
understand and process only the data that it does understandTous les champs qui ne sont pas explicitement décrits, ne sont pas standards et sont susceptibles d'être ignorés
De plus, le GEDCOM définit une seule forme qui correspond à ce qu'acceptait PAF et tous les tags qui ne sont pas décrit, provoquent des erreurs dans ce logiciel.
Ajoutons cette phrase page 23 :
Tags from Appendix A (see page 83) must be used in the same context as
shown in the following form. User defined tags (see <NEW_TAG> on page 56) are discouraged but
when used must begin with an under-score. Ce qui interdit d'utiliser un tag existant (TIME par exemple) dans un contexte qui n'est pas décrit.
Il en résulte, que même si TIME serait utile là où vous le mettez, il n'est pas autorisé.
Par contre un tag maison (_TIME) est parfaitement autorisé.
Il s'agit bien d'un lien direct vers la page du registre de l'acte et pas un lien vers le site des AD. Pour REPO:WWW je verrais plus https://archives.cotedor.fr/
Même motif, même punition.
WWW n'est autorisé que dans une structure d'adresse.
Pas d'adresse, pas de WWW.
j'ai pas mal d'autres corrections aussi mais je ne vais pas toutes les faire car il semble que la norme soit beaucoup moins permissive que ma logique et que je soit dans l'erreur et en même temps je comprend pourquoi aucun logiciel ne respecte complètement la norme.
Je me contenterai donc d'obtenir un fichier suffisamment bien structuré pour être correctement interprété si j'estime que certaines modifications sont contre productives, si elles me paraissent légitimes je corrige.
Vous commencez à comprendre que le GEDCOM n'est pas un formalisme que pour le plaisir et chacun fait sa tambouille comme il le veut.
C'est pourtant ce qu'on cru pas mal d'éditeur de logiciel pendant 20 ans.
Les logiciels peuvent respecter la norme et avoir les informations qu'ils veulent, mais il faut faire l'effort de comprendre la logique.
Rien ne les empêchait de créer leur propre forme et de faire ce qu'ils voulaient. En voulant faire du LINEAGE-LINKED, il faut respecter ce que les mormons ont décidés il y a plus de 20 ans. (La version 5.5.1 date de 1999)
Pour ce qui est des OBJE (je suis hors sujet mais c'est mon explication pour le bout d'un objet embarqué dans une autre entité) ce qui se passe c'est qu'en client lourd, j'ai beaucoup de fichiers, qui sont des captures d'écran d'actes.
Pour un évènement j'ajoute une source et j'ajoute ce screen à la source, le logiciel traite ça comme ça INDI:BIRT:SOUR => SOUR:OBJE => OBJE:FILE donc le logiciel les traite comme des fichiers multimédia mais ce ne sont pas des OBJE multimédia au sens photo de mariage mais bien acte de mariage.
Jusque là ces enregistrements OBJE et la façon dont ils sont pointés depuis l'évènement me semblent techniquement logiques bien que la transcription soit stockée dans SOUR:DATA:TEXT.
En revanche, lorsque je met à disposition ma généalogie sur le site de mon hébergeur, je dispose de 500Mo restants ce qui est bien suffisant, mais ces screens occupent 3go d'espace disque, donc ils sont stockés sur un cloud (pour ceux qui ne s'affichent pas directement, comme les portraits) et donc OBJE:FILE qui pointait sur un fichier jpg local est remplacé par son URL cloud.
La norme accepte pour OBJE:FILE un fichier en local ou sur une ressource réseau (type partage ou NAS) mais pas une ressource réseau type cloud donc oui une erreur est remontée mais au final c'est le même fichier.
Je ne suis pas sur d’avoir tout compris.
Dans FILE, vous mettez ce que vous voulez. Le fait qu'Ancestris ne puisse pas lire le contenu n'est pas en soit une erreur de formalisme.
Certes les méthodes d'affichage d'une ressource locale et cloud diffèrent mais il n'y a pas de raison logique de supprimer l'OBJE pour le placer dans SOUR:WWW (dans lesquelles sont inscrites les permaliens vers les AD) si ce n'est une raison technique (le visualiseur photo windows ne va pas pouvoir ouvrir le fichier mais le navigateur pourrait le faire).
Bref je ne sais pas un jour si cette norme prendra en charge ce type de mécanismes mais étant donné, à mon sens, que ces liens on leur place là où ils étaient jusque là, dans OBJE:FILE, ou mieux, dans OBJE.WWW vers leurs transcriptions (mais là encore j'ai des erreurs ;-) ) la solution que j'ai retenu c'est de supprimer tous les OBJE liés à des sources et leurs références dans ces sources et de placer une note dans l'évènement "Source : https://monlienversmonfichier".
Bien sûr je parle de modifications uniquement sur un ged destiné à être importé pour une mise à disposition sur le net.
OBJE:WWW n'est pas valide, SOUR:WWW n'est pas valide.
La seule manière valide de définir un objet multimédia est OBJE:FILE, de définir dans OBJE:FILE:FORM le format du document
Voilà désolé de vous embêter avec toutes ces questions mais grâce à vos réponses j'y vois déjà plus clair.
Je ne vous reproche pas de respecter la norme bien au contraire et je sais bien que la hiérarchie des données par rapport à leur contenu est difficilement prévisible mais ces nuances ont, je trouve, leur intérêt dans la description précise de leur contenu et le fait de limiter l'usage de balises à une hiérarchie précise est dommageable (FAM:MARR:DATE:TIME ne me semble pas déconnant).
Peut être également que ma méthode de travail n'est pas la bonne et que je me retrouve confronté à des difficultés qui n'ont pas lieu d'être...
Il manquerait plus que vous nous reprochiez de respecter la norme....
La problématique de votre approche c'est que vous modifiez manuellement un fichier pour une utilisation particulière en cherchant à être conforme à une norme qui n'est peut-être pas utilisée par votre destinataire.
Si votre objectif est de mettre vos données dans Webtrees, voyez avec Webtrees les arrangements qu'ils ont faits avec la norme pour intégrer les données.
Ancestris essaye de redresser pour que les données soient comprises par le plus grand nombre de logiciel.
Ce n'est pas forcément adapté à votre usage.
Si votre seul intérêt est de valider votre GEDCOM, il existe des validateurs :
https://chronoplexsoftware.com/gedcomvalidator/https://ged-inline.org/A mon humble avis ils vous diront que vous ne pouvez pas faire n'importe quoi avec la norme.
Zurga
