viewer: resolve bundle-relative markdown links in concept bodies - #362
Open
aadehamid wants to merge 2 commits into
Open
viewer: resolve bundle-relative markdown links in concept bodies#362aadehamid wants to merge 2 commits into
aadehamid wants to merge 2 commits into
Conversation
The viewer's rewriteInternalLinks only rewired hrefs in OKF's
recommended absolute form ('/tables/customers.md'). Bundles that use
the relative form explicitly allowed by SPEC 6.1 (e.g.
'../entities/foo.md' — common when bundles are also read in tools
like Obsidian) fell through to the external-link path, and following
them in a browser produced ERR_FILE_NOT_FOUND instead of navigating.
Pass the current concept id into rewriteInternalLinks and resolve
relative hrefs against its directory (handling '.' and '..' segments
and URL-encoded characters such as %20). A relative target that
resolves to an existing concept now navigates within the graph,
matching the absolute-form behavior; targets that do not resolve
still open externally.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
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
1 participant
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.
Problem
The detail panel's
rewriteInternalLinksonly rewires hrefs in OKF's recommended absolute form (/tables/customers.md). Bundles that use the relative form explicitly allowed by SPEC §6.1 (e.g.../entities/foo.md) fall through to the external-link path. Following such a link in a browser producesERR_FILE_NOT_FOUNDinstead of navigating within the graph.Relative links are common in practice for bundles consumed by more than one tool — e.g. a bundle also read as an Obsidian vault, where relative links (with URL-encoded spaces,
../entities/My%20Concept.md) are the form Obsidian itself generates and resolve natively.Note the inconsistency this creates within the viewer itself: the Python side already handles relative hrefs correctly —
_extract_linksresolves them against the document directory when building graph edges — so the graph edges exist and render, but the same links are dead in the detail panel.Fix
rewriteInternalLinksnow receives the current concept id and resolves relative.mdhrefs against its directory. A newresolveRelativehelper handles./..segments and decodes URL-encoded characters such as%20..md/scheme/anchor hrefs keep the existing external-link behavior.Testing
node --checkpasses on the patched file.ERR_FILE_NOT_FOUND; after, a sampled 178/178 relative hrefs resolve to concept ids and navigate correctly._extract_links) were unchanged before/after the patch, confirming the body-link path now agrees with the edge path.