Penn-Maen a écrit :il y aura toujours quelqu'un pour inventer une nouvelle unité (genre "3 bols de pale +2 casseroles de blé"...)
Oui mais non. La spécification donne une liste d'unités acceptables et on ne doit pas en sortir. Encore une fois, une application peut faire n'importe quoi avec ça, mais ce sera hors spec.
Penn-Maen a écrit :Les tsp, cup et autres unités de ce type : pas le droit, point. Système SI dans le fichier, et chaque soft se débrouille ensuite pour convertir dans l'unité locale.
Dans l'absolu ça m'irait ! Mais on a bien vu que les devs (parfois même ceux qui avaient participé à la spec) ne le respectaient pas. Je préfère un truc qui est plus complexe mais où les données sont sûres.
Si tu te souviens de notre discussion de l'autre jour, j'aurais préféré rester en unité SI et faire du name and shame sur ceux qui respectaient pas.
Penn-Maen a écrit :
Pour les unités et leurs multiples/sous-multiples : pourquoi ? Une voiture ou un semi-remorque, ça se pèse en tonne(s). Pourtant la carte grise est toujours en kilogrammes. Donc on n'est pas "obligé" d'utiliser des unités différentes dans le fichier, mais les softs sont eux libres d’interpréter la valeur pour la rendre lisible à l'humain. Car dire "ce n'est pas format destiné à être lu par un humain" d'un coté, et de l'autre faire usage des multiples ou sous-multiples d'une unité qui ne sont que pour la lecture humaine est un peu antinomique. Un ordinateur se fout éperdument que l'humain se sache pas compter le nombre de zéro avant/après une virgule
Encore une fois, je suis assez d'accord. Dans l'absolu, j'aurais préféré que tout soit en g (par exemple) et qu'il y ait un champ qui donne une unité d'affichage. Ça aurait permis de préserver l'intégrité de la valeur tout en permettant de dire si un ingrédient s'exprime en g en cuillère à café ou en tasse.
Penn-Maen a écrit :Note : une solution de validation serait aussi un plus. Comme les XML validator. C'est peut-être un truc qui manquait pour le Bxml, et du coup chacun y est allé de sa petite modif ..
Justement, vu que la spec est un JsonSchema, toute recette sera validable. Dans le repo Github, il y a déjà de quoi le faire justement. Ça ne concernera toutefois que la forme et non le contenu (du Special B à 300 °L passera alors qu'en vrai c'est 300 EBC. En revanche, 300 "mon unité non définie dans la spec" ne passera pas).
Jean-Luc a écrit :Tout standard est soumis aux interprétations de chacun. Le beerxml n’y échappe pas.
Un bon standard ne doit justement laisser aucune place à l'interprétation. A mon sens, BeerXML a été fait dans cette idée, mais le manque de validation et le fait qu'il soit abandonné comme format primaire et contourné par ses propres créateurs a pas aidé à sa stabilité effective.
Jean-Luc a écrit :Créer un nouveau “standard” (du coup pourquoi appeler ça un standard...), est il la bonne solution ?
Je crois qu'il y a confusion sur le terme standard. Dans le langage courant, on imagine que c'est quelque chose qui a été choisi et qui est utilisé par tous. En vrai, on peut créer un standard seul et l'utiliser seul. Techniquement, ça reste quand même un standard. En l’occurrence, ce n'est pas un nouveau standard, mais une évolution du BeerXML. Il est d'ailleurs directement présenté comme la version 2.x.x.
Jean-Luc a écrit :
Le beerxml a été conçu comme une aggregation de données en multiniveaux (recette/style/matériel/brassage/fermentation.../ingrédients/.../)
Une recette en beerxml “complète”, en accord avec le format, contient toutes les données nécessaires et détaillées, profils matériel, brassage, style, etc... et pas juste de quoi afficher son résumé.
Mais si les unités sont répétées et détaillées pour chaque élément c’est pour que chaque élément soit autonome : pour qu’en important une recette dans un programme on puisse récupérer la totalité d’une “brique” de données : 1 houblon avec son usage et ses caractéristiques, 1 profil de matériel complet prêt à utiliser, 1 levure, 1 profil de brassage ou de fermentation etc...
Chacune de ces briques pouvant alors enrichir l’inventaire et les profils personnels.
Du coup, récupérer d’une recette tel ou tel ingrédient, avec sa couleur et son unité pour la convertir facilement, plutôt que se demander dans quelle unité l’ensemble de la recette est calculée, ça peut faire du sens.
Entièrement d'accord avec ça, c'est toujours le cas en BeerJson 2 pour le peu que j'en ai lu.
Jean-Luc a écrit :Sinon pour un nouveau format, je reste quand même dubitatif sur la naissance d’un format qui se voudrait aussi un standard, quand celui qui existe est si peu ou si mal utilisé, ou compris.
Au final tout le monde veut être universel, et tout le monde veut être différent.
Je partage pas cet avis par contre.
Encore une fois, c'est pas un nouveau format, mais une évolution du BeerXML. J'ai pas encore assez joué avec pour voir si c'est facile de passer de l'un à l'autre, mais ce sera sûrement un point critique à son adoption.
En revanche, le BeerXML 1 est pour moi définitivement obsolète :
- Il ne couvre pas l'intégralité de ce dont tout logiciel de brassage a besoin (houblonnage, acides, ...)
- Il a été totalement dévoyé et c'est irrécupérable
- Son format (le XML) est une technologie dépassée
- Il n'est plus maintenu (mis à jour)
Je pense que c'est tous ces points que BeerJson veut corriger. Il a aussi l'avantage d'être facilement convertible en BeerXML pour exporter les données pour les applications n'utilisant pas la nouvelle version.