FHIR Chat · Resolving references in Bundles · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: Resolving references in Bundles

Lloyd McKenzie (Feb 17 2021 at 06:09):

I've finally completed writing up what I think is the appropriate algorithm for references inside Bundles - in a comment at the end of FHIR#29271. Please review and provide feedback.

ryan moehrke (Feb 17 2021 at 16:36):

is the draft under review your most recent edited comment?

Lloyd McKenzie (Feb 17 2021 at 20:49):

Yes

Josh Mandel (Feb 17 2021 at 21:41):

The writeup includes language like "the server MAY look " -- I think "server" refers to "entity processing the Bundle"?

Josh Mandel (Feb 17 2021 at 21:42):

The branch including "Look for an entry with a fullUrl that matches the versionless reference and a resource.meta.versionId that matches the reference's version id." seems to end without covering all cases.

Josh Mandel (Feb 17 2021 at 21:43):

The language about "f (sic) there are entries in the Bundle with no fullUrl entries, the system MAY choose to parse the absolute reference to extract the 'id' and check for a match on the presumption that the base URL for the missing fullUrl would be the same as the absolute URL in the reference"... this feels kind of open-ended. Is it strictly necessary?

Josh Mandel (Feb 17 2021 at 21:45):

Resolving relative references against a UUID base.
This feels like unnecessary complexity to me, and seems to introduce new requirements.

Josh Mandel (Feb 17 2021 at 21:50):

Overall -- WOW, this is a complex process! I worry about implementability / consistency of implementations.

Paul Church (Feb 17 2021 at 22:01):

I was going to comment on jira but this might be easier to discuss here. This proposal confuses me even more than the existing text - some of these sections have multiple layers of "MAY" and parenthetical statements. The tree of conditional possibilities is even deeper than before. Resolving relative references against a UUID base seems to be an entirely new idea and I don't see a use case for it.

Paul Church (Feb 17 2021 at 22:01):

I see two basic use cases for references in bundles:

Paul Church (Feb 17 2021 at 22:02):

1. The most common case that I see in my world, and what I recommend for applications constructing bundles for operational purposes, is that a reference to Patient/123 simply means Patient/123 on the server the bundle is being sent to, and if you want internal bundle references put a urn:uuid in the target resource's fullUrl and use urn:uuid to refer to it.

Paul Church (Feb 17 2021 at 22:02):

2. The other case is a pure data exchange where https://example.com/fhir produces a bundle in which every resource has a fullUrl prefixed with https://example.com/fhir and every reference is a relative reference that has to be interpreted against that restful base.

Paul Church (Feb 17 2021 at 22:05):

There are additional considerations for versioned references, conditional references, references by identifier, and references to some random fullUrl that we're not going to try to resolve. But the basic cases are referring to things on the server trying to process the bundle, and referring to things in the bundle.

Paul Church (Feb 17 2021 at 22:16):

Also to reiterate an earlier comment I am in favour of not putting any details in this section about resolving references by identifier, other than the first point "The server is not required to perform any resolution whatsoever." It seems like a contradiction to say it's server-specific behaviour and then give a set of rules in the specification for doing it!

Vassil Peytchev (Feb 17 2021 at 23:09):

Maybe there are different rules for different types of Bundles? I think the rules for Transaction/batch, search-set, and messages/documents might be different (as in certain things are allowed or not allowed for each group)

Lloyd McKenzie (Feb 18 2021 at 00:17):

@Josh Mandel

• will fix reference to server.
• will finish second branch
• we need to cover situations where fullUrl is left unspecified. It's unfortunate we allowed fullUrl to be omitted, but given we did, we need to handle it
• agree this is complex. I'd love to mandate fullUrl and prohibit in-bundle identifier resolution and conditional reference resolution. However, that ship appears to have sailed. We could possibly split it into two sections - good practice resolution (complex enough) and "special cases" for where systems do things that are allowed but unnecessary and which we encourage you to not support so senders will stop creating unnecessary work...

@Paul Church

• Relative references with urn:uuid: is something that's been supported by the tools for a while and I know is in use in some production systems (necessary or not). Given it was never explicitly discussed, we'd have grounds for prohibiting it, but it would create implementer pain. (Especially because they're using the Java validator in production.)
• We already have short descriptions of how to handle resolution of identifiers and the change request was to be more explicit.

@Vassil Peytchev
I'm not aware of any rules that say that conditional references or identifier references are prohibited except in certain cases? (Happy to reflect if there's a rule though - the more we can push them to the edges, the better.)

Josh Mandel (Feb 18 2021 at 02:36):

Re: "create implementer pain," endorsing extra/complex behaviors may be net more pain than proscribing them, even if a small number of current systems behave in ways outside of the spec (they can continue to work and just be non-conformant in this one small regard; no need to spread the complexity everywhere)

Lloyd McKenzie (Feb 18 2021 at 02:54):

Well, only if the Java validator continues to support the behavior...

Vassil Peytchev (Feb 18 2021 at 16:27):

I didn't mean conditional references or logical references specifically. My first reaction was about relative references possibly referencing resources on a server (outside of the bundle):

• in Transaction/Batch, it makes sense that they are referencing resources on the server where the transaction/batch is posted
• in search results, it makes sense the they are referencing resources on the server that performed the search
• In a message or document it makes sense that they would only be relative to the fullUrl base of the resource, if the fullURL is a proper URL and not a URN.

If we are looking at all the possible ways references could be written and then resolved, it seems that in some cases some variants may be prohibited, while in other they may be useful.

On fullUrl in the form urn:uuid or urn:oid - I can't see any reasonable argument to have "paths" following the UUID or OID, and that should be disallowed.

Lloyd McKenzie (Feb 18 2021 at 16:36):

You definitely can't have paths following the uuid or OID

Elliot Silver (Feb 18 2021 at 17:08):

Lloyd McKenzie said:

You definitely can't have paths following the uuid or OID

What about a link to the initial version of a newly created resource?

Lloyd McKenzie (Feb 18 2021 at 19:53):

You still wouldn't have anything following the uuid or OID...

Elliot Silver (Feb 18 2021 at 19:55):

What about "uurn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12/_history/a"?

Lloyd McKenzie (Feb 18 2021 at 19:56):

How is that meaningful/possible? How can there be history on something that doesn't have any existence outside the Bundle?

Lloyd McKenzie (Feb 18 2021 at 19:56):

Do you have a specific use-case?

Elliot Silver (Feb 18 2021 at 19:57):

I want my provenance to link to the original version of the resource I'm creating, not to later updates.

Elliot Silver (Feb 18 2021 at 20:01):

See J#14138

Lloyd McKenzie (Feb 18 2021 at 20:13):

So you're not wanting to point to a version so much as to say "when this transaction gets executed, the link should be version-specific"?

Elliot Silver (Feb 18 2021 at 20:17):

Right, and I think that's what the current existing text intended to convey -- you can tag a version on the urn, but don't expect that version number to actually be used, the server will use whatever it picks. Although the current text implies a server will never pay attention to the specific number, which is incorrect when you are referring to an existing (versioned) resource. (Hmm, gets even weirder when you start talking about conditional creates).

Paul Church (Feb 18 2021 at 20:21):

This sounds like what the X-Provenance header is trying to accomplish, making the Provenance resource refer to the specific version created by the operation it's attached to.

ryan moehrke (Feb 18 2021 at 20:22):

so will you only need that concept in transaction bundles?
or is there some other interaction you're thinking of?

Paul Church (Feb 18 2021 at 20:22):

http://hl7.org/fhir/provenance.html#header - but it's unclear how this works with a bundle

Lloyd McKenzie (Feb 18 2021 at 20:26):

That works for Provenance. But if you're wanting to create an Encounter and a Condition and say "this Encounter needs to point to this specific version of the Condition", you can't use the X-Provenance mechanism to accomplish that

Paul Church (Feb 18 2021 at 20:28):

Yep, I've looked at that in the past and there really isn't any way. It's not trivial to actually implement such a thing either, as the referring resource should be updated in the same transaction but the version of the referent may not be known until after the transaction commits - if it's based on a commit timestamp, for example.

Elliot Silver (Feb 18 2021 at 20:29):

ryan moehrke said:

so will you only need that concept in transaction bundles?
or is there some other interaction you're thinking of?

I don't know of other places where we expect urns to "resolve." (Identifiers? Identifier or code systems?)

Elliot Silver (Feb 18 2021 at 20:32):

I'd forgotten X-Provenance. It seems like a straightforward change to describe how it would work on a transaction bundle. I'd also add in language that the transaction can either contain a Provenance resource or the X-Provenance header. Although as Lloyd points out, there are like other cases beyond Provenance that would still need to be addressed.

Elliot Silver (Feb 18 2021 at 20:42):

@Paul Church , J#31345.

Vassil Peytchev (Feb 18 2021 at 21:44):

I am missing how we get from

What about "uurn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12/_history/a"?

to

I want my provenance to link to the original version of the resource I'm creating, not to later updates.

I think the following applies from section 4.1 of RFC 8141:

Because a URN is, syntactically, a URI under the "urn" scheme, in theory a URN can be placed in any protocol slot that allows for a URI [...]

However, this does not imply that, semantically, it always makes sense in practice to place a URN in a given URI protocol slot; in particular, because a URN might not specify the location of a resource or even point indirectly to one, it might not be appropriate to place a URN in a URI protocol slot that points to a resource

Elliot Silver (Feb 18 2021 at 21:52):

We get to it by:

• in a transaction bundle, uuids stand in for the id of a to-be-created resource.
• resource ids can be appended with ./_history/X to refer to a specific version of that resource.
• I want to refer to a specific version (in this case, the initial version) of a to-be-created resource.
• Based on that set of rules, uuid/_history/X should be able to refer to version of the newly created resource.

Vassil Peytchev (Feb 18 2021 at 22:10):

My understanding is quite different:

In a transaction bundle, fullUrl can contain a urn:uuid or urn:oid value, solely for the purpose of enabling references within the bundle to this particular resource.

Assuming that these fullUrl values will be used in any way outside of the bundle seems to be a stretch (IMO, all the way to non-conformance), and as far as I know is not documented anywhere.

Assuming that the uuid in from a urn:uuid fullUrl "stands in for the id of a to-be-created resource" is also quite a stretch.

There is likely a much more sensible way to refer to the initial version of the to-be-created resource.

Lloyd McKenzie (Feb 18 2021 at 23:27):

The intention isn't that the urn:uuid can be used outside the Bundle. It's being used as a temporary id in the transaction to support linking. The question is how you indicate that you want the linking to be version-specific when you're using that temporary id mechanism.

Vassil Peytchev (Feb 18 2021 at 23:59):

In other words the Provenance resource is in the bundle as well?

Lloyd McKenzie (Feb 19 2021 at 00:04):

Yes. Or in my example, both Encounter and Condition are in the bundle.

ryan moehrke (Feb 19 2021 at 00:19):

the other question I would have is: is there any use-case where you need to specify which version of a resource you want to point to (vs that you want to point to whichever version of the resource the current transaction creates)
because in my mind, if we can specify that there is no reason why you would need this paradigm outside of a transaction bundle, and no reason why you would need to point to more than 'current' version (but explicitly) then we could have more of a flag or something indicating 'this temporary reference is version specific and should be replaced as such' - whatever that version may actually be - instead of having to figure out how to apply /_history to a uuid etc.

Paul Church (Feb 19 2021 at 00:32):

I can't see such a use case (pointing to a version other than what the transaction creates) because if you don't know the identity of the resource, you wouldn't know the version ID that you want to point to.

Elliot Silver (Feb 19 2021 at 00:46):

I can't think of a reason to point to anything but the latest/only version of a created resource, although I can think of uses that might point to a specific version of an existing resource.

Don't forget about conditional create though--there may be historical versions of a "new" resource. Again though, I can't think of a use for pointing at a previous version of a resource you are conditionally creating.

Lloyd McKenzie (Feb 19 2021 at 00:58):

You would be pointing to the version created by the transaction. The thing is that you're wanting the refence to be locked to that version, rather than floating and just pointing to the object in general - such that as the referenced thing changes, you'll always end up with the most recent version when traversing the link.

Lloyd McKenzie (Feb 19 2021 at 00:58):

In the Encounter/Condition example, I want the Encounter to point to the specific version of the Condition I'm creating now - with this transaction, such that even if the Condition changes in the future, the Encounter always refers to this specific version.

ryan moehrke (Feb 19 2021 at 00:59):

But if you want to point to an existing version of an existing resource you can just call it out by the RESTful url right?
so I'm not sure how exactly our final version will look like, but theoretically something like versioned:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12 may be better than uurn:uuid:9d1714da-b7e6-455b-bfd2-69ce0ff5fb12/_history/a that would only mean anything in a transaction bundle

Elliot Silver (Feb 19 2021 at 01:02):

@ryan moehrke , except that we have a mechanism for version references defined in the current spec, and we don't have anything defined for "version:". Going with anything other than saying "a uuid followed by /_history followed by anything will point to the created version" is a breaking change.

Lloyd McKenzie (Feb 19 2021 at 01:02):

Sure. If you're wanting to point to a version that exists outside the Bundle, then you'd use a proper reference. The sole requirement here is "please establish a link to this other thing in the Bundle and, by the way, please ensure the link is version-specific". We don't have a good way (that I know of) to do that. Which is what @Elliot Silver is asking for.

ryan moehrke (Feb 19 2021 at 01:35):

Where do we write that /_history is the only way that urls can reference a version specific resource? the only mention here https://www.hl7.org/fhir/references.html is in an 'eg.' example that just implies vRead format can be used. Is that really enough to call adding a specific keyword to call out this niche case a breaking change? nothing I can find anywhere else uses stronger language and sometimes doesn't even call out /_history at all.

And yes, Lloyd I know that referencing resources that exist outside of the bundle is not the scope of the question,, I was responding to " although I can think of uses that might point to a specific version of an existing resource. " as the only given case where my use-case restrictions may not cover. But as you mentioned that is not in scope for the question anyways.

Also to be clear I'm not saying that version: is our best bet. I'm just trying to pose that we shouldn't be twisting around existing formatting if we don't need to. If uuid/_history/blah is still better than sure go for it, but since as far as we can think this formatting will only be used in 1) a transaction bundle and 2) to point to whatever version will be created by another interaction in said transaction bundle
I'd think something explicit would be better than overloading /_history

Lloyd McKenzie (Feb 19 2021 at 04:10):

I'm not arguing for throwing /_history on the end of a urn:uuid:.... In fact, I'm pretty sure that's not an option. Whatever the reference is, it must be a valid URI. If the URI starts with "urn:uuid:", then it has to follow the rules for that URN syntax - and throwing "/_history" on the end isn't it. It may be that the solution is to put an extension on the reference.

Certainly if you're going to refer to a specific version of an existing resource, using the full history URL is the only way to do this - and is the completely REST-appropriate way to do so.

Vassil Peytchev (Feb 19 2021 at 04:50):

Or we can cheat get creative:

1. reference.reference="urn:uuid:aaa-ss-fsdg" in a transaction means always create a reference to the initial version of the resource created (if the server supports history)
2. reference.identifier="urn:uuid:aaa-ss-fsdg" in a transaction means always create a non-versioned reference to resource created.

Lloyd McKenzie (Feb 19 2021 at 05:02):

We can't use a single special id. There could be many (even hundreds) of distinct resources that each need version-specific links. Plus hard-coding GUIDs is a recipe for disaster. If GUIDs are the same across instances they're supposed to refer to the same resource. I'd much prefer an extension. At least that's clean and explicit.

Vassil Peytchev (Feb 19 2021 at 07:41):

I think I didn't explain properly my (originally tongue-in-cheek) proposal.

1. The purpose of having a fullUrl of the format urn:uuid or urn:oid is to provide Identity to resources that don't have one. In particular, in transactions/batch Bundles, such fullUrls can be used as a reference pointer to resources that are yet to be created.
2. References can be literal (URL) or logical (identifier).
3. UUIDs and OIDs are by definition identifiers.
4. Based on the above, and the quote from RFC 8141, it seem to me that the proper way to reference resources within a Bundle where the fullUrl is in the format urn:uuid: or urn:oid, is to use reference.identifier.value
5. With a couple of well thought-out new values for reference.identifier.use and reference.identifier.type we can get a clear and deterministic solution to the original problem (and add clarity to the general issue of resolving references on s bundle).

Lloyd McKenzie (Feb 19 2021 at 14:16):

If a Reference.identifier is specified, there's no expectation the server will resolve it. It's certainly not treated like a Reference.reference

Vassil Peytchev (Feb 19 2021 at 14:32):

There is current language that sets such an expectation for internal references in a bundle

Note, in addition, that a reference may be by identifier, and if it is, and there is no URL, it may be resolved by scanning the ids in the bundle.

Lloyd McKenzie (Feb 19 2021 at 14:46):

Not that requires resolution

Lloyd McKenzie (Feb 19 2021 at 14:46):

And even if it did, there's no expectation they'll get turned into references

Gino Canessa (Feb 19 2021 at 16:17):

Given that FHIR servers aren't required to even support versioned resources, wouldn't it be better to make an extension (e.g., <base>/treat-as-version-specific-reference)? This could be placed either on the reference itself, or on the bundle (for allowed bundle types).

Lloyd McKenzie (Feb 19 2021 at 17:02):

I'd put it as an extension on the Reference. Typically this would be something that would vary from reference to reference.

Gino Canessa (Feb 19 2021 at 17:10):

Makes sense to me - I wasn't sure if the use cases were more along the lines of 'everything in this transaction should be reference version locked'.

Lloyd McKenzie (Feb 19 2021 at 17:16):

Not generally. References to Patient or Practitioner would rarely be appropriate to be version-locked. On the other hand, references to Condition or Questionnaire commonly would be.

Elliot Silver (Feb 19 2021 at 17:19):

Gino Canessa said:

Given that FHIR servers aren't required to even support versioned resources, wouldn't it be better to make an extension

I don't buy this as motivation. What is the behaviour for existing resources if a client includes a version reference and the server doesn't support versions? We already have mechanisms to deal with this.

If we are going to create an extension, I'd suggest something like "reference current version", and allow it to be used for any resource, existing or newly created.

However, I stand by my position that the resolution previously agreed to was to support _history on uuids, and that any change to that is a breaking change.

Lloyd McKenzie (Feb 19 2021 at 17:21):

It's only a breaking change if it was documented in the spec somewhere. And given that the solution would automatically have been broken (because it would have resulted in an invalid URI, breaking a different rule), correcting it would qualify as a technical correction

Gino Canessa (Feb 19 2021 at 17:23):

You can't allow /_history on a UUID - it is not a valid URN.

With that requirement, I much prefer an extension over building in more conditional processing complexity.

Edit: my note about server support relates to the conditional nature of the processing - I think any major intention in Bundle would need to handle both situations.

Vassil Peytchev (Feb 19 2021 at 17:37):

You can't allow /_history on a UUID - it is not a valid URN.

More precisely, it is an invalid URN in the UUID namespace.

Elliot Silver (Feb 19 2021 at 17:43):

Well, the response to J#14138 makes it pretty clear that we intended it to work the way I've described. And I'm not arguing whether it is a valid URN or not, I'm pointing out that I believe it to be a breaking change.

Also, Lloyd McKenzie previously said:

It would be <guid>/_version/xyz, but otherwise yes.

I'd really like @Ewout Kramer, @Grahame Grieve or someone else involved in the original discussion to chime in.

Gino Canessa (Feb 19 2021 at 17:54):

I don't think FHIR#14138 says anything about UUIDs at all. I do agree the intention is to ensure that version-specific references in allowed in transactions, but disagree that it discussed UUIDs.

The referenced ticket (FHIR#14005) specifically asks about it, and the resolution is:

Question answered in #14138. You don't need to use urn:uuid, you can have a "symbolic" FHIR reference with a version indication to make this work.

Which (to me) reads that you cannot use a UUID for a versioned reference, but can use a symbolic one.

Elliot Silver (Feb 19 2021 at 17:57):

Yeah, I reread J#14005 too. I don't recall what a "symbolic" reference is.

Gino Canessa (Feb 19 2021 at 18:01):

I think Lloyd could be more authoritative, but I assume it is just referring to assigning a local URI with a version (e.g., Patient/123/_history/3) within the bundle - knowing that the ID and version will be replaced during processing.

Lloyd McKenzie (Feb 23 2021 at 03:33):

I've updated the proposed language based on our discussions today. Look at the last comment:
https://jira.hl7.org/browse/FHIR-29271

ryan moehrke (Feb 23 2021 at 15:57):

I like it, but I think this is a typo:
"Note that the rules for resolving references in contained resources are the same as those for resolving resources in the resource that contains the contained resource. I.e. the fullUrl of the containing resource is used when determining the base for relative references, etc."
bold is my emphasis: that should be "same as those for resolving references in the resource" right?
that whole 'contained' blurb feels a bit wordy, but I don't have a better proposal so I'm not kicking and screaming for it to change.

Lloyd McKenzie (Feb 23 2021 at 16:15):

Fixed

Vassil Peytchev (Mar 08 2021 at 23:20):

Well, after accepting the resolution today, I finally remembered what I meant by resolving the references on the server for Batch and Transaction Bundles.

Scenario: A transaction that contains an Entry of an observation, that points to a patient. In the entry for the observation, the request method is POST, and therefore, the fullUrl is either missing, or it is a URN. The referenced patient is not part of the Bundle, since there are no changes to that resource.

I think it is appropriate in this case to require an attempt to resolve the relative reference Patient/123 against the FHIR server where the transaction/Batch is posted.

Lloyd McKenzie (Mar 09 2021 at 00:33):

And it needs to be a relative reference rather than absolute why?

Vassil Peytchev (Mar 09 2021 at 00:44):

Because that is how it would look if it wasn't a part of a transaction. Requiring that it has to be an absolute reference would make things harder in cases of a multi-step preparation of transactions/batches.

Lloyd McKenzie (Mar 09 2021 at 02:16):

@Yunwei Wang Can you put this on our agenda to evaluate again next week?

Paul Church (Mar 09 2021 at 22:01):

I think this is the key point - if I POST an Observation containing a relative reference "Patient/123", the POST has no fullUrl for the Observation. There is an expectation (although perhaps I'm expecting too much and it's not spelled out anywhere?) that the server will interpret that reference relative to the server's base.

But if I then wrap that same POST in a transaction bundle, that expectation disappears?

Joe Lamy (Apr 22 2021 at 21:35):

Based on the final language in https://jira.hl7.org/browse/FHIR-29271, any references using reference.identifier fail to resolve. What does it mean to fail in this context? I thought the intent was that servers may choose to resolve identifiers but are not required to.

Lloyd McKenzie (Apr 22 2021 at 21:37):

We don't dictate what failure to resolve means. Servers are allowed to treat it as an error, warning or ignore. Or to fail to even try to resolve in the first place.

Elliot Silver (Nov 17 2021 at 16:19):

Reviving this old thread... did an extension ever get created to specify a reference should be version-specific?

John Moehrke (Nov 17 2021 at 16:36):

Is it allowed for me to update Provenance definition with an 'informative' guidance that would 'guide' data recipients (e.g. servers) to upgrade Provenance.target references to a version specific reference WHEN that recipient is a versioning service, and when the request was to create/update with provenance (e.g. use of X-Provenance header, bundle transaction/batch with create/update and a Provenance)? This would be consistent with the current recommendation for Provenance.target to be a version specific id, but is indeed new guidance to upgrade non-version links to version specific links.

John Moehrke (Nov 17 2021 at 18:10):

This referring to FHIR-31345 that is asking for Provenance.target handling

Lloyd McKenzie (Nov 17 2021 at 21:57):

@Elliot Silver did a tracker item ever get created?

Elliot Silver (Nov 17 2021 at 22:24):

I don't recall creating one, and searching Jira for "version" is useless. I can create one if needed.

Lloyd McKenzie (Nov 17 2021 at 23:36):

If you can't find one, creating one is the first step I guess

Elliot Silver (Nov 17 2021 at 23:48):

OK. Rereading the thread, is there a need for a second to clarify not appending _history to urns?

Lloyd McKenzie (Nov 18 2021 at 00:13):

Sounds like a good idea

Elliot Silver (Nov 19 2021 at 00:00):

J#34342, J#34344, and for fun J#34345.

Alexander Zautke (Feb 09 2022 at 12:15):

I'm trying to implement the new proposed algorithm in the context of resolving a resource within a FHIR document. One question regarding the following section:

Extract the [root] from the Bundle entry's fullUrl and append the relative reference to it (e.g., "https://fhir.example.org/" + "Patient/123" --> "https://fhir.example.org/Patient/123")

Does this imply that all bundle fullUrls, if they are absolute urls, need to have the same root? Otherwise how am I supposed to pick the correct root? Or would I need to try out all potential combinations?

Josh Mandel (Feb 09 2022 at 14:32):

The snippet you quoted above is how you turn a relative reference (within a Bundle.entry.resource....reference) into an absolute one. Having constructed this value, you can look for a sibling Bundle.entry whose Bundle.entry.fullUrl equals your constructed value. I'm not sure what "potential combinations" you're referring to. An example might help here.

Alexander Zautke (Feb 09 2022 at 15:43):

I was talking about the situation where you have a bundle containing fullUrls with multiple roots. When resolving the relative reference, I missed the part that you would extract the root of the fullUrl of the entry containing the relative reference. You should not assume that all roots are the same within the bundle and therefore extract the root from any fullUrl.

Alexander Zautke (Feb 09 2022 at 15:45):

Makes definitely more sense :) Thanks!

Josh Mandel (Feb 09 2022 at 15:51):

Quite so. If there are clarifications you think would have been helpful here, please do suggest updated language! We've been trying to make this more approachable.

Last updated: Apr 12 2022 at 19:14 UTC