Add support for Excel-like expressions and references

[danionita]

Formulas are <AttributeName,e3Expression> tuples attached to any model element. An e3Expressionmay be a number or a logical Excel-like expression containing references to other attributes, either local or of other objects. References can be of four types: e3{attributename} -> legacy local e3{#objectId.attributename} -> legacy external (by uid) e3{'objectName'.attributename} -> new external (by name) e3{ElementType('name').attributename} -> old external (by name)

Example (using the old external (by name) syntax):

[bobismijnnaam]

I do not think it is a good idea to support the fourth syntax. Semantically it means it also looks in the "namespace" of an entity (I think this is what it says in the pdf). So let's say you're writing a formula for a value interface. You write e3{ValueOffering('in').COUNT}. You then expect the value offering of specifically this current value interface to be picked. However, actually I'm just "ignoring" the ValueOffering part and checking if there is a UID for the name 'in'. Obviously there are many value offerings with the name in (one for every value interface), so that's going to mess up the formula.

To the user the whole idea of these concepts is irrelevant/messy anyway. And it adds extra complexity to the evaluation step of the model. (unless I'm missing something and this is what you intended). The directly naming approach is better afaik.

[danionita]

Why would there be many value offerings named "in" if we enforce global unique naming?

Best regards, Dan Ionita

On Oct 2, 2016 3:25 PM, "Bob Rubbens" notifications@github.com wrote:

I do not think it is a good idea to support the fourth syntax. Semantically it means it also looks in the "namespace" of an entity (I think this is what it says in the pdf). So let's say you're writing a formula for a value interface. You write e3{ValueOffering('in').COUNT}. You then expect the value offering of specifically this current value interface to be picked. However, actually I'm just "ignoring" the ValueOffering part and checking if there is a UID for the name 'in'. Obviously there are many value offerings with the name in (one for every value interface), so that's going to mess up the formula.

To the user the whole idea of these concepts is irrelevant/messy anyway. And it adds extra complexity to the evaluation step of the model. (unless I'm missing something and this is what you intended). The directly naming approach is better afaik.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/54#issuecomment-250971150, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjEpD-lr7NKLxMeazfLkD-zNfeElxHMks5qv7DJgaJpZM4JmtnI .

[danionita]

I agree it might be confusing to have 4 syntaxes. But it also means the old user manual still applies.

Best regards, Dan Ionita

On Oct 2, 2016 3:25 PM, "Bob Rubbens" notifications@github.com wrote:

I do not think it is a good idea to support the fourth syntax. Semantically it means it also looks in the "namespace" of an entity (I think this is what it says in the pdf). So let's say you're writing a formula for a value interface. You write e3{ValueOffering('in').COUNT}. You then expect the value offering of specifically this current value interface to be picked. However, actually I'm just "ignoring" the ValueOffering part and checking if there is a UID for the name 'in'. Obviously there are many value offerings with the name in (one for every value interface), so that's going to mess up the formula.

To the user the whole idea of these concepts is irrelevant/messy anyway. And it adds extra complexity to the evaluation step of the model. (unless I'm missing something and this is what you intended). The directly naming approach is better afaik.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/54#issuecomment-250971150, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjEpD-lr7NKLxMeazfLkD-zNfeElxHMks5qv7DJgaJpZM4JmtnI .

[bobismijnnaam]

Well, right now the user cannot name value offerings. Value offerings are a leftover from jaap's e3value ontology, but we don't actually use them in the editor to generate RDF. Hence, if we also enforce unique naming for the value offerings, the rdf exporter will generate names like "in8", "in32", etcetera. This will make it (even more) impossible for the user to refer any value offerings to begin with, since the user cannot guess which number we will use for which value offering.

I guess it boils down to a different question: do we want to expose the user to legacy ontology features such as value offerings? Or do we hide them from the user? If we hide them, we don't need the fourth syntax, and it will keep the implementation simple and straightforward as it is now. If we don't hide them, well... :(

[danionita]

We don't need the fourth syntax. With our unique naming assumption it is obviously redundant and there is no reason to use it instead of referring to elements by name or id directly. The reasons to support it are: (1) backwards compatibility and (2) it's easy (just ignore the object type and only parse the name).

The issue regarding "legacy" features is unrelated imo. We have to support the entire e3value ontology, and the RDF generated should be backwards-compatible. The relevant question is then: which concepts does the user see or is able to interact with? The value offering, similar to value transactions, is a concept which was always hidden from the user, even in the old editor. Since the user does not have the ability to attach formulas to hidden elements, there is no reason to refer to the attributes of these elements in formulas.

[bobismijnnaam]

Alright. I think the editor supports the fourth syntax, I'll double check it next time I work. Besides that this feature is mostly implemented now, right? (Then I'll close it next time)

[bobismijnnaam]

Woops.

[danionita]

As far as I have checked, this works properly.