@Nicolas-Boltz and I discussed the implications of changing the format and we have the following proposal:

• A constraint (does not matter whether text file via CLI or web editor) starts with a bullet point *, followed by an optional space and the name of the constraint which may be any string until the delimiter :
• Afterwards, the constraint logic is written down as is
• The next constraint starts again with the bullet point *

By doing this, we both unify the formats but also require to we always name constraints (which significantly helps the understandability a couple of years later) and we also simplify the web editor. The constraints window than simply shows a multiline text editor without the need to manually add constraint entries (which is bad UI, as discussed in our last meeting).

Example for a valid constraint:

* DataOwnership: 
    data Sensitivity.Personal 
      neverFlows 
    vertex Location.nonEU
* SomethingCompletelyDifferent: data Sensitivity.Special neverFlows vertex Location.nonSpecial

It's important that the name can be accessed in DSLResult. Without a link between violation and constraint, batch processing becomes tedious.

As a DSLResult only contains violations for one TFG and is constructed by an AnalysisConstraint it should be enough to be able to access the name from there, right?

@Nicolas-Boltz and I discussed the implications of changing the format and we have the following proposal:

* A constraint (does not matter whether text file via CLI or web editor) starts with a bullet point `*`, followed by an optional space and the name of the constraint which may be any string until the delimiter `:`

* Afterwards, the constraint logic is written down as is

* The next constraint starts again with the bullet point `*`

By doing this, we both unify the formats but also require to we always name constraints (which significantly helps the understandability a couple of years later) and we also simplify the web editor. The constraints window than simply shows a multiline text editor without the need to manually add constraint entries (which is bad UI, as discussed in our last meeting).

Example for a valid constraint:

* DataOwnership: 
    data Sensitivity.Personal 
      neverFlows 
    vertex Location.nonEU
* SomethingCompletelyDifferent: data Sensitivity.Special neverFlows vertex Location.nonSpecial

Done in 057224b. I however would opt for using - instead of * for listing constraints, as that is more common in Markdown, and other plain text based file formats

Thank you. We intentionally choose the asterisk as it is less common in names (especially compared to the dash used to combine words), and additionally, the asterisk is already reserved as wildcard. However, allowing both would also be fine.

I would implement both, but just as a note (and consideration):
After reading the List Token (e.g. - or *) and an optional Space, we allow all characters until we encounter our name delimiter (so :). This would allow users to define any names they like, even ones with spaces or other (normally) reserved characters, like * or -.
Therefore, we would not have any conflicts when using -.

Considering this, would we still allow both?

It's important that the name can be accessed in DSLResult. Without a link between violation and constraint, batch processing becomes tedious.

As a DSLResult only contains violations for one TFG and is constructed by an AnalysisConstraint it should be enough to be able to access the name from there, right?

I could build around it. But for the sake of traceability I'd prefer a link between Result and Constraint