Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recursively describe symbols that appear in a model/definition #751

Closed
niazim3 opened this issue Jul 4, 2018 · 4 comments
Closed

Recursively describe symbols that appear in a model/definition #751

niazim3 opened this issue Jul 4, 2018 · 4 comments
Assignees

Comments

@niazim3
Copy link
Collaborator

niazim3 commented Jul 4, 2018

(Moved from #350)
The data definition for GlassBR's GTF is missing the descriptions for the elements in the mapped set in the generated version. This is the manual version
image and this is currently generated
image. I believe this may end up being related to the potential solution of recursively describing the symbols that appear in a model/definition (see smiths/swhs/issues/35 for that discussion).

@JacquesCarette
Copy link
Owner

I think this might be straightforward - whatever currently does the recursive traversal seems to not traverse the lhs of the case construct properly.

@smiths
Copy link
Collaborator

smiths commented Jul 9, 2018

@niazim3 thank you for highlighting this. We should definitely consider using a recursive traversal, especially if it is straightforward. Another option to consider is to manually add a data definition for glass types. This would give us something that we could explicitly point to for traceability. Another option is to assume that the reader will consult elsewhere to find the meaning of AN, FT etc. I don't like this option though because in some cases we might not include this information anywhere else.

@samm82
Copy link
Collaborator

samm82 commented Jul 20, 2018

A possible workaround - we could add it to the Notes section, as it seems like "additional information".

@smiths
Copy link
Collaborator

smiths commented Jul 21, 2018

Adding to the notes section is a good solution for now. We might consider the other ideas in the future, but adding to the Notes section would let the generated version match the manual version, so that we can close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants