You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
v3.2: Consider requiring $self to be an absolute-URI #4548
this seems like the exact situation where you want to use absolute $self value. I thought the idea of distinguishing URIs -- identifiers -- from URLs -- locators -- is that you could have the same document in multiple locations and would want to make clear that it is the same document -- with a single identifier -- even though it could be retrieved from multiple locations.
Restricting $self to absolute URIs would break the analogy with $id but would simplify things.
This is somewhat related to issue #4541 which questions the decision to have API URLs ignore$self because if you do have multiple API instances, hosting a copy of the OAD in a location relative to the instance allows using the same OAD at runtime to work with multiple API instances.
This contrasts with $self which is concerned with the load-time identity of the individual document. We would still use other RFC3986 sources (including the retrieval URI if no base URI is available from an encapsulating entity) for the base URI when $self is not present, but we would no longer have to explain/support the "what if $self is relative" scenario.
We had a lively discussion about whether a relative $self is useful when its absence would mean falling through to the retrieval location anyway. Please add your thoughts here async and we will revisit this discussion.
Activity
lornajane commentedon Apr 24, 2025
We had a lively discussion about whether a relative $self is useful when its absence would mean falling through to the retrieval location anyway. Please add your thoughts here async and we will revisit this discussion.
lornajane commentedon May 15, 2025
Final discussion: support both relative and absolute (see #4556 (comment))