_generalrestrictions
cr8onski opened this issue · comments
In the examples there is a "_generalrestrictions" template which seems to be a template which defines rules and determining properties to be applied to every template of a given profile. A sort of pretest for every statement claiming to be part of a profile before then finding a specific template to match. I can find no reference nor guidance for this in the specification.
I was going to have a go at answering this but when I realized that in cmi5 at least, the _:generalrestrictions template isn't used in any of the patterns, I got confused. Shouldn't it be used in all of the patterns?
The reason there's no guidance is there's nothing special about that template; it works like all the others. Since it has no determining properties, all statements (using the profile) match, per the rules on determining properties, and thus must follow the rules given.
It doesn't appear in the patterns because there's no place in cmi5 where you can send a statement that just follows those rules. Every place statements can be sent, they have other specifications, manifested in other statement templates, that determine how they're allowed to slot in.
Well to me this was not an obvious template to add, though I do find it valuable. I was surprised when I saw it being used in some of the example templates. Then when I went back to look for guidance and explanation in the specification could find none, and had some lingering questions. One of which is how does this square with the requirement to ensure that a statement will match at most one template?
The one-template requirement is only a SHOULD right now, and I've started thinking we should get rid of it entirely (there are lots of other scenarios too where non-exclusion is good that've come up while working through example profiles).
We'll get rid of it, no more SHOULD