This was still marked as In Review, while this is still in the discussion phase. Moved it back one status.

I moved everything that’s not in 2.2.0 or 2.3.0 to 3.0.0 for now, so we can decide later in which specific version it should go.

I vaguely remember eventually not doing it, and so it would be an error that it is in the change log - I can remove that easily enough of course. I suggest that we push this to ADL 3.x or a higher ADL 2.x since to really do it properly needs to be on the basis I mention above, i.e. that there could be archetypes that are ‘standalone’ and effectively operate as RM schemas, i.e. instead of BMMs. But we’d need to document that fairly extensively, because its a different approach to the basis of the current specs - notwithstanding the fact that the UPV team have it working. It could certainly be made to work, but it is a fair bit more complex than the innocent change originally suggested.

In the change log this has been supposedly done in 2.0.0. However, it is not currently part of the specification. Has it been reverted after that
Should I move this to ADL 3.0.0 for now, or keep it here?

You can still parse archetypes, just you will not know some things about some objects and attributes that you may need when working with them later.

Specific to how the ‘some formal representation’ works in Archie, you can easily add your own BMM files, and parse, validate and flatten the archetypes using those with the public API. I’ll add how to do that to the documentation soon.
If you have a model implemented as java classes, Archie has a reflection based metamodel representation you can use. It’s also possible to implement an entirely different mechanism if you need that by just implementing an abstraction layer, and the validator, flattener and OPT generator will work - although some other tools such as the example instance generator require a full BMM model.