Specify the OPT 2 ADL syntax for C_ARCHETYPE_ROOT with child nodes

I’ve been doing some implementation and testing with the proposed way of doing this, i.e. writing matched archetype_id into the C_ARCHETYPE_ROOT.archetype_ref field. Problems I’ve found so far:

• there is no way to distinguish at node level whether a C_ARCHETYPE_ROOT is in a source form archetype or template. or in an OPT;

• the existing concept of path extraction (/attr[id-code]/attr[id-code]) doesn't produce valid paths from an OPT, since the id-codes can be from different archetypes down the hierarchy.

Problem 1 can be gotten around by looking at the owning archetype, but that’s reasonably annoying - a better approach might be to have a dedicated attribute in C_ARCHETYPE_ROOT that contains the matched archetype id.

The solution to the second presumably involves defining some more complicated notion of a path, like:

• /attr[id-code]/attr[id-code, archetype_id]

• /attr[id-code]/attr[id-code and @archetype_ref = "archetype_id"]

• /attr[archetype_id::id-code]/attr[archetype_id::id-code]/attr[archetype_id::id-code]

I’d probably favour specifying the last one of these as a reliable path for OPTs. Which kind of implies that the C_ARCHETYPE_ROOT.node_id should have archetype_id::id-code written into it at the root points. If we don’t do this, we should define a path node generator function on C_ARCHETYPE_CONSTRAINT that usually just extracts node_id but for C_ARCHETYPE_ROOTs within OPTs, extracts archetype_ref::node_id.

In any case, the usual path extraction algorithm produces wrong results (i.e. /attr[id-code]/attr[id-code]).

OPT 2 works, as does its JSON and XML serialization. Just this lack of a syntax in ADL means that ADL serialization of OPT 2 is not currently fully specified. And this construction happens in nearly every instance of an OPT.

Just to be clear, you’re saying that OPT2 won’t work because of the syntax i.e. not using 'use_archetype'? Or something else?

This was only discussed in the sec chat on discourse so far. It is a big omission in OPT 2 though, since this is necessary for every OPT including another archetype to work

I’ll try to regenerate the HTML - I think more people will need to be able to do so anyway. I created it as a pull request as a proposal, only to merge after discussion in a call and agreement.

Was this discussed in a SEC call? I’m ok with the change, but are the other implementers? I’ll probably cancel the pull request on the spec if that's the case, because I’ll need to do your change but also add the CR info to the rev hist and regenerate the HTML.

On the question of the validity rule, I don’t think I agree - you might want to define some archetype that just re-uses some other archetype directly - i.e. it’s a pure reuse case, not a slot-filling case.