-
Notifications
You must be signed in to change notification settings - Fork 181
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
Enhancing 'link' to indicate internal targets in a 'resource' #756
Comments
The following are two possible ways to address this issue. 1. extra fragment
In the above the This approach complicates writing constraints that enforce the link to back-matter resource relation. It also complicates resource resolution, since the two fragments will need to be pre-parsed. 2. Extra flag
In the above the This approach requires handling the fragment outside the Which to choose?We are interested in feedback on these options. Thoughts? |
Neither of the two ways accommodates a |
During the 8/5 model meeting, there was discussion of back-matter chaining related to resolving resources (potentially across referenced documents). We need an example and clearer specification around how to handle this. @david-waltermire-nist will work up some examples to illustrate such cases. |
I think that option number 2 seems a lot cleaner. When actually implementing the back matter links, I think having to parse the |
Issue #567 was an earlier issues exploring this topic, with some suggestions around a way forward. |
Perhaps if we provided Then multitudinous This is not a perfect solution but builds cleanly on what we have, and it avoids a number of potential complications in both link and resource maintenance (given that resources may be both 'abstract', and have multiple representations available). |
@wendellpiez One thought... If a specific This would avoid a case where we would need multiple coordinates to select the |
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
True, that is one potential solution, i.e. break out the links. Don't try and provide the "link base" functionality in a As to that, perhaps we need to clarify how the "role" of an rlink in a resource is distinguished, if there are multiple (such as JSON and XML versions of the "same document", or backup copies). I.e. which kinds of (over)loading of rlinks into a resource are legit, vs which ones you're on your own with. One reason why extending the notation at the other end is that an element-id pointer only works on XML targets, for example. But what if the document you are linking to is in JSON? a pointer syntax has to work for either doesn't it? |
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
Defined a constraint to validate the allowed characters for a fragment. Resolves #756.
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
Defined a constraint to validate the allowed characters for a fragment. Resolves usnistgov#756.
User Story:
Sometimes I need my data to point not just to a document, but to a location inside that document, as in
<link href="target.xml#id1"/>
to point to an element withid="id1"
in a document found attarget.xml
.This doesn't work, however, when using an indirect link via
resource
inside an OSCAL file:By OSCAL link traversal, a link to a
resource
resolves into a link to the resource itself. However, this does not help us to target an identified location inside that resource.Goals:
One simple solution would be to provide
link
with a new flag such asref-id
, to indicate the ID of a target within a linked resource.@ref-id
would effectively alias the href#
fragment identifier syntax inside@href
values, but would also work on targets indicated by reference toresource
elements.If "ref-id" is too ambiguous (it should not be the ID of the resource but a string representing an ID inside the document it references) we could come up with another name.
This idea would be much easier for developers to support than the proposal outlined in #567 addressing the same requirement.
Dependencies:
This proposal addresses the requirement described in Issue #567, albeit with a different mechanism. (Instead of extending the W3C-defined href linking syntax, we use OSCAL). If this proposal is adopted, we can close #567 and spin part of its effort (describing / documenting link construction) into a separate one.
Additionally, this Issue could be included in the work for #597 (an epic covering model enhancements).
Also, update the document, model, or constraint additions with changes in PR associated with #1023 following its approval and merge in the context of this work, although not an explicit dependency. See #1023 (comment) for more details.
Acceptance Criteria
The text was updated successfully, but these errors were encountered: