j'ai lu (et implémenté en écriture) la doc, en laissant de coté tous les champs "non obligatoires".
Résultat :
- des fichiers XML valides
- des imports dans les softs ou sur les sites plus que foireux
En fait, les problèmes sont de 2 ordres :
- d'un coté, les auteurs de soft/lib autorisent les créateurs de recettes à utiliser n'importe quelles unités, y compris des unités "variables"
(je vais y revenir juste au paragraphe suivant) absolument pas définie dans la spec BeerXML 1 → problème de "rédaction" : le fichier sera valide, mais difficile à interpréter lors d'échanges
- de l'autre, lors des imports, les softs/lib, confronté à des unités exotiques et absolument pas SI, font de leur mieux pour faire rentrer des rond dans des carrés, avec plus ou moins de bonheur. C'est normal.
Pour prendre juste un exemple type, je vais illustrer le cas des levures.
Dans la doc, la quantité de levure est définie soit en litre, soit en kilogrammes
(on peut reconnaitre aux auteurs, tous américains, le mérite d'avoir imposé ce type d'unité).
Dans la plupart des softs, on défini la quantité de levure soit en sachets, soit en "vials", en "packs", en...
Pour avoir un xml correct (et pas simplement valide), il faut convertir les sachets/vials/packs en kilogramme ou en litre.
Alors, question :
- un sachet : 6,10, 11, 11.5, 12, 12.5, 100, 500 grammes ?
- one vial : 40 ou 125 ml ?
Pareil pour les grains, avec une couleur codée normalement en lovibond, mais avec des valeurs qui sont dans 95% des cas du SRM (ou des EBC/1.97), voire carrément en EBC ou panaché. On retrouve aussi quantité de recettes avec des valeurs sans unités, puis, tout à coup au détour d'une balise, "pof", le terme EBC qui apparait.
- Un grain à 1000 lovibond, ça fait très noir quand même. On fait quoi chef ?
- Fait comme si t'avais rien vu !
- Mais chef, peut-être, que tout est en EBC ?
- Tout Grain le bleu, fait comme de rien, et importe moi cette recette fissa !
- Bien chef, mais les résultats vont être incohérents !
- Ce n'est pas notre problème le bleu, z'avaient qu'à pas coder avec leurs pieds, ou mettre tous leurs orteils d'accord sur les unités. Alors tu importes, et tu te grouiles, car là, j'ai water-poney !
- d'accord chef, mais...
- Tout grain le bleu !!!
L'avantage, et aussi la faiblesse du xml, c'est sa souplesse : n'importe qui peut interpréter ce format à sa sauce, y rajouter des balises ou des valeurs
(dont la lecture ne sera implémentée nulle part, forcément ).
pourquoi ne pas étendre le format avec des valeurs supplémentaires ?
c'est l'idée, mais encore faut-il que les developpeurs de soft et lib en circulation se donnent la peine de l'implémenter
(sinon, autant faire juste des rajouts de commentaires "<!-- -->", ou trouver un vieux violon pour p***** dedans )ou mieux ça interprète n'importe comment
c'est une partie du problème actuel
(certainement lié au fait que les premiers a avoir implémenté le format —les auteurs du beerxml— se sont rapidement permis de faire tout et n'importe quoi en dehors des specs qu'ils avaient eux même définis, preuve s'il en est qu'il y avait des manques... Tiens, ça rappelle IE6 à quelqu'un ? ) Si c'est un format d'échange, il doit être strict, et donner les mêmes résultats quel que soit le soft utilisé. Pour illustrer le propos, faites l'expérience suivante : télécharger une recette sur internet, ouvrer là dans un soft, ré-exporter là, rouvrez-la avec un second soft, et observez le résultat... C'est peut-être ressemblant, mais de là à dire qu'il s'agit de la même bière, des fois, c'est osé
Le sujet n'est pas de taper sur qui que ce soit
(le beerxml, c'est comme les topics ici : ça dérive rapidement ), mais peut-être de faire réfléchir sur :
- la faisabilité d'un format d'échange, simple, ouvert, facilement compatible avec le Bxml 1
(et pourquoi pas un format uniquement réservé à l'échange de recettes ). Pas un truc pondu à la va-vite, fini à la hussarde et plein de manques.
- la façon de faire adopter ce format par les auteurs de softs/lib/api qui circulent sur le web (soyons optimistes !). Pour faire plus court, qu'est-ce qui aiderait Brad à faire le choix de ce format
(il est leader, donc s'il choisi ce format, d'autres suivront certainement) ?
- voir ce qui est bien et moins dans le format actuel
(si ce n'est ce problème d'unité, et tant qu'on reste toujours avec le même soft , il suffit à peu prêt pour l'usage "moyen", mais visiblement, ce n'est pas le cas pour tous)