Repository navigation
fix(solid): keep a literal's base direction from read to write - #655
Merged
Merged
Conversation
A literal with an RDF 1.2 base direction ("..."@ar--rtl) that another
app wrote into a pod document lost its language and direction when
the app read the document. Every later write of that document then
held a literal typed rdf:dirLangString with no language, which the
write check rightly refuses, so a save of the preferences, the
palettes or a large card edit, and any edit of that value, failed
until the document was fixed outside the app. A Studio draft that
held one could neither be edited nor published.
Both clients now keep such a literal with its language and direction,
in every dataset made from what was read, and tell two values apart by
their direction in a dataset's changes. A dataset made from an RDF/JS
dataset is now built as a read builds one, so it keeps the direction
too and holds a repeated triple once. A draft's statements carry the
direction as well, and tell "x"@ar from "x"@ar--rtl, and so does the
check that a release already in the pod is the one being published.
The PATCH body, the release writer, the JSON-LD export and the test
pod's store write the direction after the language. The write check
accepts a well-formed one: a language and ltr or rtl on a literal
typed rdf:dirLangString. It still refuses one with no language, no
direction or any other direction, or a direction on any other literal.
The app writes no direction of its own. Such a literal is not read as
text in a language, so the getters of that text leave it out, and
setting a property's strings keeps it. It shows nowhere new and stays
as data that is written back as it was read.
Refs: GHSA-vgv2-vh37-7c34
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 literal with an RDF 1.2 base direction (
"…"@ar--rtl) that another app wrote into a pod document lost its language and direction when the app read the document. Every later write of that document then held a literal typedrdf:dirLangStringwith no language, which the write check rightly refuses, so saving the preferences or palettes, a large card edit, or any edit of that value failed until the document was fixed outside the app. A Studio draft holding one could neither be edited nor published.@direction) and the test pod write the direction after the language.ltrorrtlonrdf:dirLangString) and still refuses one with no language, no direction or any other direction, or a direction on any other literal.docs/data-model.mdstates the rule.No test yet runs this against the real pod servers in CI, so whether each accepts
@ar--rtlin a write is not shown here.Refs: GHSA-vgv2-vh37-7c34