Spike: multi-version IG

[johngrimes]

A spike against #335 exploring whether the SQL on FHIR IG can publish ViewDefinition as a real FHIR resource type rather than a logical model, and whether multi-version packages can ship for R4 alongside the primary R5 build.

The diff in this PR is small (3 files, +40/-5) and produces R5, R4, and combined .tgz packages out of the box. It is offered as a starting point for working group discussion. The broader exploration that produced this commit also surfaced a number of IG publisher gaps the WG may want to be aware of before committing to this direction; those findings are below.

Changes

input/fsh/models.fsh: re-parents ViewDefinition from CanonicalResource to DomainResource so the IG publisher can convert it back to R4 (R4 has no CanonicalResource abstract type). The canonical-resource metadata fields (url, identifier, version, name, title, status, experimental, date, publisher, contact, description, useContext, jurisdiction, purpose, copyright) are declared directly on the resource so the on-wire shape is unchanged.

sushi-config.yaml: adds two IG parameters.
custom-resource: fsh-generated/resources/StructureDefinition-ViewDefinition.json tells the publisher to promote kind=logical to kind=resource and register ViewDefinition as a custom resource type. This IG is on the approved list at https://fhir.github.io/ig-registry/igs-approved-for-custom-resource.json. The published package now contains a kind=resource SD plus 11 example instances at package/custom/ViewDefinition-*.json rather than the previous Binary-*.json placeholders.
generate-version: r4 makes the publisher emit a sibling org.sql-on-fhir.ig.r4.tgz with *.r5 dependencies rewritten to *.r4 (hl7.fhir.uv.extensions.r4, hl7.terminology.r4, etc).

input/pagecontent/StructureDefinition-ViewDefinition-notes.md: updates two Binary-* example links to ViewDefinition-* since the publisher renames example files when the resource type is promoted.

Build outcome

Errors: 38, Warnings: 66, Info: 54, Broken Links: 17. Three packages produced under output/: package.tgz (R5, 144 KB), org.sql-on-fhir.ig.r4.tgz (R4 sibling, 159 KB), package-combined.tgz (89 KB). The errors and broken links are mostly pre-existing markdown / anchor issues unrelated to this change.

Findings worth flagging to the WG

The semantically correct flag for this is actually additional-resource, not custom-resource. The FHIR Tools IG describes the difference as: custom-resource is a type the IG uses but does not publish; additional-resource is a type the IG publishes for others to consume. additional-resource sets the http://hl7.org/fhir/tools/StructureDefinition/additional-resource extension on the SD, which downstream tooling can use to discover "new resource types this IG introduces". custom-resource does not.

We tried switching to additional-resource and ran into several integration gaps in the IG publisher (master, 2.2.7 release):

The handler only accepts XML files. SUSHI only emits JSON. Workaround requires a post-SUSHI conversion step in the build script.

Every additional-resource requires a bundle-<TypeName>-search-params.xml alongside it (PublisherIGLoader#loadSearchBundle). For new resource types with no search parameters yet, this has to be a hand-written empty Bundle stub.

The renderer at StructureDefinitionRenderer#scanForKeyElements hard-codes http://hl7.org/fhir/StructureDefinition/<typeTail> when looking up an element's base type. For SDs whose URL is in the IG canonical namespace, this lookup returns null and rendering profiles of the resource type crashes with a NullPointerException. This is recoverable by giving the SD a URL in the core FHIR namespace (http://hl7.org/fhir/StructureDefinition/ViewDefinition) and adding special-url-base: http://hl7.org/fhir, which is the pattern HL7/data-access-policies, HL7/admin-incubator, and HL7/immunization-incubator use.

When a hand-written XML SD is placed in input/resources/<typename>/ (the documented location, where SUSHI uses it as a predefined resource for compiling profiles and instances), the publisher's additional-resource handler caches it at PublisherIGLoader.java:1043 and the auto-loader caches it again at loadConformance1/cacheResourceFromPackage (line 4252) with package version metadata applied. This produces "Ambiguous type ViewDefinition" at output-generation time. We could not reproduce this against an fhirVersion: 6.0.0-ballot3 IG using the same setup as the working IGs above; switching this IG to R6 produced a clean build (9 broken links, all pre-existing markdown anchors), with the SD properly published carrying the additional-resource: true extension. We did not isolate exactly what the version-difference depends on.

We also looked at whether IGs can supply cross-version maps (StructureMap) for instances of their custom resource types, so a single IG could ship usable R5 and R4 sibling packages. The publisher's generate-version only auto-converts core FHIR types via hard-coded version converters (VersionConvertorFactory_X_Y.convertResource); it has no hook for IG-supplied conversion maps, and the OtherVersions slot on FetchedResource is only populated for StructureDefinition and SearchParameter (PublisherProcessor#generateOtherVersions). Without an upstream change there is currently no way to ship working R4/R5 sibling packages that include the ViewDefinition type and its instances.

Refs #335.