Relationship between `OBJECTS` and `FORMULA`

[mjacoby]

What is the relationship between OBJECTS and FORMULA?

Assume this example rule which is a valid rule according to the grammar

ACCESSRULE:
  ATTRIBUTES:
    CLAIM("email")
  RIGHTS: READ
  ACCESS: ALLOW
  OBJECTS:
    IDENTIFIABLE $sm("*")
  FORMULA:
    $match(
      $aasdesc#endpoints[].interface $gt REFERENCE($cd(*)#idShort),
      $startswith($aas#submodels.id, $smdesc#semanticId.keys)
    )

Clearly, this does not make sense as the object we are talking about is a submodel and therefore has no AAS descriptor, AAS, or submodel descriptor.

The only thing that might be related to this I could find in the specification was

A formula referring to undefined attributes shall result in false. Any type of error during the evaluation of a formula shall be treated as if the formula resulted in false. Source

I assume that by undefined attributes you mean exactly those elements that don't make sense. However, we need a formal definition of what undefined attributes are and I think this depends on OBJECTS.
A table/matrix might be a suitable way to represent this, at least in the case where we have a single entry in OBJECTS. Having multiple OBJECTS entries targeting different AAS element types probably causes a lot of issues and should prohibit the use of most (if not all) expressions targeting AAS elements in the formula.

• I have signed the required Developer Certificate of Origin (DCO) already.

[Martin187187]

I agree that there is currently a gap here.

OBJECTS defines the resources to which the permission applies, while FORMULA further constrains whether the permission is effective. However, the specification does not yet define precisely which AAS objects are available to FieldIdentifiers during evaluation.

I don't think we can define this simply based on the type used in OBJECTS. For example, existing rules combine ROUTE with $sm#..., and CREATE rules may target a Submodel while evaluating $sme#... for the element being created. With multiple OBJECTS and different operations, there are many possible combinations.

Therefore, we need a general definition of the evaluation context and what happens when a FieldIdentifier cannot be resolved. In particular, such cases should have deterministic fail-closed semantics and must never accidentally grant access.

Concrete normative evaluation semantics are already planned in PR #79. I think this case should be covered there as part of defining FieldIdentifier resolution and error handling.