Repository navigation
fix(solid): keep only the classes a draft's subject writes - #736
Merged
Merged
Conversation
A release draft keeps another app's statements of its subjects as they are and writes them back on every edit, its rdf:type ones among them. The write check holds a subject to the shape of every class it has, so a class that a shape asks something of, given to the draft's deck, a card or another subject the draft reads by its shape, made every later edit of that subject fail. On the deck, the draft could no longer be edited at all. The writer already drops such classes from a subject it records, but the draft added them back from its kept statements. Reading a draft now keeps, of a shaped subject's other classes, only those its write keeps: no class a shape asks something of, none past the most the check reads, and no type that is no IRI. Writing a draft, made or changed, holds what it writes of such a subject to the same rule, whatever its statements carry. Publishing a draft leaves the classes it does not keep out of the release too, so the release holds what the check of the draft sees. The rule is the one records.ts writes a subject by, now shared as keptClasses. Refs: GHSA-8hh7-p2ww-mpjf
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
A release draft keeps another app's statements about its subjects as they are and writes them back on every edit,
rdf:typestatements included. The write check holds a subject to the shape of every class it has. So if a draft's deck, one of its cards, or another subject the draft reads by its shape was given a class that a shape asks something of, every later edit of that subject failed. On the deck itself, the draft could no longer be edited at all. Writing a subject outside drafts already drops such classes, but the draft added them back from its kept statements.When it reads a draft, the Studio now keeps only the other classes of a shaped subject that a write would keep:
Writing a draft, whether it is new or changed, holds what it writes of such a subject to the same rule, whatever its kept statements carry. Publishing a draft also leaves those classes out of the release, so the release holds what the draft's check saw. The rule is the one
records.tsuses to write a subject, now shared askeptClasses.docs/data-model.mdanddocs/shapes.mddescribe it.Refs: GHSA-8hh7-p2ww-mpjf