There were several discussions over the last 3 years mentioning the possibility to express archetypes in a more popular format other then the ODIN-ADL and XML. One of the option considered was YAML. I was exploring a bit this, tried a few things and came up with following results for two of the arc…

[image] ian.mcnicoll: does it remain computable ‘down the tree’? This cannot be specified in the current version of BMM. Thomas says it could be added to BMM3. Implementers must be careful to add those simpler formats to the serialization/deserialization code. This way it should remain compu…

I thought we were going to do JSON first then other formats, since for JSON we have a canonical JSON Schema (I don’t remember if it covers the whole AOM/TOM 1.4 though). For other formats we might need some kind of schema to be able to validate the syntax.

[image] borut.jures: Avoiding ADL would lower a barrier to entry for new implementers I really care about this one. [image] borut.jures: For them YAML requires more “key strokes” than ADL. I don’t think writing adl by hand to produce an archetype is really done by anyone. Mostly it’s …

About those simplifications that flattens some value (occurrences , terminology codes etc) - we can do that for sure, but I intended to first produce a yaml that is close to AOM serializations, without any extra logic. But Like I said, this is just an experiment and a discussion point.

[image] joostholslag: I don’t think writing adl by hand to produce an archetype is really done by anyone. Mostly it’s doing 99%from a gui editor. But making specific edits for edge cases or tool failure by hand in adl is a key requirement imho. So nr of key strokes is not really an issue I think…

For experimentation, the ADL Workbench generates a 100% YAML flat form archetype for any archetype. I have not checked if the YAML is completely correct for a long time, but if people want to use it, I can fix any errors pretty easily. [image] siljelb: See how the DV_QUANTITY element “Systolic”…

Ok, but for the record, I don’t want to divert this post into advocating YAML vs JSON vs ODIN benefits - I only want to explore the following: “if” we would choose YAML then how should that look like. There is so far no decision taken towards using YAML, but we just need to explore it. @thomas.be…

My openEHR blood_pressure attached. It’s from the ADL2 form, so id-coded (ADL WB doesn’t know about at-coded ADL2 yet). DIfferences appear to be: AWB version is outputting lists (‘-’ leader) in some places where it should be outputting maps (no ‘-’) AWB doesn’t output any typenames AWB version on…

[image] joostholslag: [image] pablo: I thought we were going to do JSON first then other formats, I remember differently from SEC discussion at Nedap last November. but it wasn’t a final decision, so maybe I missed something. Editing in yaml is much much easier than json, to me. Curious …

Archetypes in YAML

Specifications ADL

sebastian.iancu (Sebastian Iancu) 13 June 2024 17:31 13

I get your point, but yaml comes besides readability also with some advantages over json, like comments, typing, tagging - basically json is a subset of yaml.

ADL formalisms

Topic		Replies	Views
JSON Schema and OpenAPI: current state, and how to progress ITS rest-apis , json	40	4702	8 April 2025
JSON for definitions-notation Technical (archive)	14	38	16 February 2019
ADL formalisms ADL	33	825	21 June 2024
a first attempt JSON archetype Reference Implementation: Java (archive)	9	18	25 November 2011
Moving on from ODIN & beyond JSON (but staying compatible) Specifications	14	1215	11 February 2021
Which AOM2 release are AWB/Nedap using for exporting OPT2 to JSON? ADL	32	1177	29 November 2021
Parsing of Archetypes/Templates Technical (archive)	10	18	12 November 2018
Separating Models from Implementation New to openEHR?	107	5663	11 December 2021
Converting ADL to JSON Reference Implementation: Java (archive)	20	31	22 April 2015
SNOMEDCT - correct representation Implementers (archive)	49	97	20 May 2017

Archetypes in YAML

Related topics