Skip to content

Enhancing 'link' to indicate internal targets in a 'resource' #756

@wendellpiez

Description

@wendellpiez

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 with id="id1" in a document found at target.xml.

This doesn't work, however, when using an indirect link via resource inside an OSCAL file:

<link href="#xxxxx">Chapter 3 in <i>Document Title</i></link>
...
<resource uuid="xxxxx">
   <title>[Document Title]</title>
   <rlink href="https://link/to/document.html"/>
</resource>

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 as ref-id, to indicate the ID of a target within a linked resource.

<link href="#xxxxx" ref-id="ch3">Chapter 3 in <i>Document Title</i></link>

@ref-id would effectively alias the href # fragment identifier syntax inside @href values, but would also work on targets indicated by reference to resource 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

  • All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
  • A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
  • The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

Metadata

Metadata

Labels

Discussion NeededThis issues needs to be reviewed by the OSCAL development team.Model EngineeringAn issue to be discussed during the bi-weekly Model Engineering MeetingScope: ModelingIssues targeted at development of OSCAL formatsUser Storyenhancementmodel-refactorUsed to mark issues related to model refactoring for the Metaschema v4 transition.

Type

No type

Projects

Status

Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions