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

Epic: Syntax error highlighting #20

Open
allantokuda opened this issue Dec 1, 2013 · 0 comments
Open

Epic: Syntax error highlighting #20

allantokuda opened this issue Dec 1, 2013 · 0 comments

Comments

@allantokuda
Copy link
Owner

This is a toggleable editor mode, that when turned on,

  • Highlights, in pale red, all LDS syntax errors (violations of the rules defined below). All items contributing to an error should be highlighted.
  • When an item contributing to an error is clicked,
    • a message should appear explaining all syntax errors on that item.
    • it should visibly bolden in a brighter red, along with the other items that contribute to the same error.
    • If an item contributes to more than one syntax error, the first in priority order (as in the list below) will be the one that causes other elements to bolden.

A graph can be saved regardless of whether it has syntax errors.

Rules:

  • Each entity, attribute, relationship, and link has an official name that is unique. (Ignore the relationship naming until that is a feature.)
  • Identifiers:
    • Each entity has at least one identifier (in its attributes, or on one of its endpoints, there should be at least one bar).
    • There cannot be any cycles of identification dependency.
      • This happens if there is a barred link from A to B, and another from B to C, and a third from C back to A.
      • Both ends of a relationship cannot contribute to an identifier. This is a special case where A depends on B, and B in turn also depends on A.
      • A reflexive relationship cannot contribute to an identifier. This is a special case where A depends on itself.
    • There cannot be a bar and a chicken foot connected to an entity that has no other bars.
    • There cannot be a bar and no chicken foot connected to an entity that does have other bars.
    • There cannot be a bar opposite a chicken foot, unless the bar connects to an entity with no other bars.
    • No identifier can be a strict subset of another. If the secondary "squiggle"-type identifier is implemented, this becomes a possibility. On an entity, the items with squiggles cannot be a strict subset of the items with bars, or vice-versa.
  • Labels:
    • A relationship has either zero or two labels.
    • All 1:1 relationships have labels.
    • All reflexive relationships have labels.
    • Between any pair of entities, there is at most one unlabeled relationship.
    • "To-be" relationships (labeled "be" at both ends):
      • They are all or nothing: you cannot label one end of a relationship "be" and the other end with anything other than "be".
      • They can only be on 1:1 relationships.
      • They cannot be on reflexive relationships.
      • Between any pair of entities, there is at most one "to-be" relationship.

These rules should be made into individual feature issues, once a an architecture is defined that will ultimately enable all of these to work.

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

1 participant