Ewout Kramer

The disadvantage of solving it in the Resolver is that each and every resolver has to be aware of this fact for resolving terminology canonicals. So I wonder: * Would...

@mmsmits - I fully agree with your analysis. E.g. the terminology service we have built for CAR files solves this with alternative indices, so this *is* something that is best...

I've almost assumed these references are "informal", but I am not sure....

Yes, if we combine that with package support (which @mharthoorn has already built) we basically have all the tools in place we need, based on the existing framework.

Why is this marked as a duplicate of #1863? This issue is about the "global" feature in the IG resource, and has nothing to do with NPM packages...

Mmmm.... `status` is a *summary* field, wonder whether we mixed that up.

Who's to decide on this one? Will we just look at the other servers, sort of reverse-engineer the logic and copy that? Or is this a [FHIR-I discussion](https://jira.hl7.org/projects/FHIR/issues/FHIR-31804?filter=allopenissues)?

First off, it seems our issue on including mandatory/modifier elements for `_elements` was a duplicate: https://jira.hl7.org/browse/FHIR-27812 / https://jira.hl7.org/browse/FHIR-31655. The verdict is: "we should **align the advice for clients and servers...

What about _summary? First `_summary = true` http://hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.isSummary > (...) When a request is made with _summary=true, serailisers only include elements marked as 'isSummary = true'. Other than Attachment.data, all...

Then, `_summary = text`. The spec says: > "Return only the "text" element, the 'id' element, the 'meta' element, and only top-level mandatory elements" After the discussion on `_element`, is...