lutaml / expressir

Ruby parser for the ISO EXPRESS language
3 stars 3 forks source link

Remarks and inheritance #18

Closed zakjan closed 4 years ago

zakjan commented 4 years ago

From the spec, 10.3.5 Scope and visibility > Explicit item rules > Entity

Attributes declared in a supertype of an entity are visible in the subtype entity through inheritance.

@TRThurman Does this apply also to remarks?

If I understand it correctly, the following example should attach a remark to val attribute:

ENTITY integer_number;
  val : INTEGER;
END_ENTITY;

ENTITY odd_number SUBTYPE OF (integer_number);
  WHERE not_even : ODD(val);
  --"val" remark
END_ENTITY;

However, the current parser only considers the textual structure of the exp file, it doesn't evaluate it. Implementing attaching remarks to a supertype from subtypes would require to fully evaluate the exp file, increasing the complexity. Can we skip this case?

TRThurman commented 4 years ago

See below.

On Nov 2, 2020, at 9:05 AM, Jan Žák notifications@github.com wrote:

From the spec, 10.3.5 Scope and visibility > Explicit item rules > Entity

Attributes declared in a supertype of an entity are visible in the subtype entity through inheritance.

@TRThurman https://github.com/TRThurman Does this apply also to remarks?

If I understand it correctly, the following example should attach a remark to val attribute:

ENTITY integer_number; val : INTEGER; END_ENTITY;

ENTITY odd_number SUBTYPE OF (integer_number); WHERE not_even : ODD(val); --"val" remark END_ENTITY; Two problems here: 'val' needs to be qualified for ease of the human reader. The parser probably doesn't care. The remark should be on the WHERE rule. -- "not_even" remark...

So this is better (in my opinion but there may be syntax errors): ENTITY integer_number; val : INTEGER; END_ENTITY; ENTITY odd_number SUBTYPE OF (integer_number); WHERE not_even : ODD(SELF\integer_number.val); --"not_even" remark END_ENTITY;

And even better would be to use the "remark tag" structure defined in EXPRESS LRM ENTITY odd_number SUBTYPE OF (integer_number); WHERE not_even : ODD(SELF\integer_number.val); END_ENTITY;

("odd_number.not_even" The value shall be odd ... ) or --"odd_number.not_even" The value shall be odd ...

However, the current parser only considers the textual structure of the exp file, it doesn't evaluate it. Implementing attaching remarks to a supertype from subtypes would require to fully evaluate the exp file, increasing the complexity. Can we skip this case?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lutaml/expressir/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMMKVCDOGGNOF2CCQNI3TTSN3DDVANCNFSM4THSN6JQ.

Thomas Thurman Principal Electrical Engineer, Rockwell Collins (Retired)

Confidentiality Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete/destroy any and all copies of the original message. E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. Therefore, the recipient should check this email and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this email.

zakjan commented 4 years ago

I agree that the example is not well written for a human. I took an example from the spec, and only added a remark, to illustrate my question about the syntax, for the purpose of the parser.

If val is referenced in a remark tag, it would be only in the scope of the closest entity integer_number directly, never in the scope of the child entity odd_number through inheritance?

i.e. --"integer_number.val" remark and never --"odd_number.val" remark?

If yes, I have the answer I looked for.

TRThurman commented 4 years ago

On Nov 2, 2020, at 9:42 AM, Jan Žák notifications@github.com wrote:

I agree that the example is not well written for a human. I took an example from the spec, and only added a remark, to illustrate my question about the syntax, for the purpose of the parser.

If val is referenced in a remark tag, it would be only in the scope of the closest entity integer_number directly, never in the scope of the child entity odd_number through inheritance?

Not necessarily. Remark tags shall conform to the visibility rules in clause 10.2 in the standard. There is no textual encapsulation nor "neighborhood" nor "closest" concept of the visibility context,

So one could have this remark 20 lines away from the ENTITY odd_number or integer_number.

i.e. --"integer_number.val" remark and never --"odd_number.val" remark?

Yes If yes, I have the answer I looked for.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lutaml/expressir/issues/18#issuecomment-720550804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMMKVE6LAOM2QDWWCBEXG3SN3HQHANCNFSM4THSN6JQ.

Thomas Thurman Principal Electrical Engineer, Rockwell Collins (Retired)

Confidentiality Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete/destroy any and all copies of the original message. E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. Therefore, the recipient should check this email and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this email.

zakjan commented 4 years ago

Lines away are fine. By closest I meant in terms of parent/child scope tree.

Remark tags shall conform to the visibility rules in clause 10.2 in the standard.

Yes, I'm following the visibility rules. The problematic sentence "Attributes declared in a supertype of an entity are visible in the subtype entity through inheritance." is in clause 10.3.5

Great that I can disregard it, thanks.

TRThurman commented 4 years ago

I think this is what you are looking for in 10.3.5: NOTE The scope of the subtype entity is not considered to be nested within the scope of the supertype.

On Nov 2, 2020, at 9:55 AM, Jan Žák notifications@github.com wrote:

Lines away are fine. By closest I meant in terms of parent/child scope tree.

Remark tags shall conform to the visibility rules in clause 10.2 in the standard.

Yes, I'm following the visibility rules. The problematic sentence "Attributes declared in a supertype of an entity are visible in the subtype entity through inheritance." is in clause 10.3.5

Great that I can disregard it, thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lutaml/expressir/issues/18#issuecomment-720558637, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMMKVF3ZGW7KILYIYVF7RLSN3I7FANCNFSM4THSN6JQ.

Thomas Thurman Principal Electrical Engineer, Rockwell Collins (Retired)

Confidentiality Notice: This e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete/destroy any and all copies of the original message. E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or contain viruses. Therefore, the recipient should check this email and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this email.

zakjan commented 4 years ago

Ok, thanks.