FHIR Chat · Core spec canonicals · IG creation

Stream: IG creation

Topic: Core spec canonicals


view this post on Zulip Elliot Silver (Sep 24 2021 at 18:21):

I was looking to confirm the canonical URL for a base resource, but was surprised that I couldn't easily locate it on the resource page. I was eventually able to find it at the bottom of the Resource content section:

See the Profiles & Extensions and the alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions & the dependency analysis

The XML and JSON "master definitions" link to the resource StructureDefinitions, which include the url.

Surely, there is a simpler way to get there, but I can't see it right now.

On a similar vein, is there an easy way to see the IG instance for an IG? It doesn't appear in the standard list of artefacts, etc.

view this post on Zulip Lloyd McKenzie (Sep 24 2021 at 19:33):

We don't have a great way to render the IG resource as its own thing. Why do you want to see it? Exposing the canonical URL for core resources will take a Git issue against the ig-publisher

view this post on Zulip Elliot Silver (Sep 24 2021 at 20:34):

It the IG resource doesn't need to be rendered, I'd just like to be able to look at it as xml/json, like I can do for everything that is in the guide. In this case, I wanted to see which resources were included in the IG, since the hand-crafted table of contents wasn't listing them all.

Exposing the canonical for core resources is a Git issue against the ig-publisher or against kindling?

view this post on Zulip Grahame Grieve (Sep 24 2021 at 20:41):

kindling

view this post on Zulip Elliot Silver (Sep 24 2021 at 20:50):

https://github.com/HL7/kindling/issues/37.

view this post on Zulip Eric Haas (Sep 24 2021 at 20:59):

It’s in the package

view this post on Zulip Lloyd McKenzie (Sep 24 2021 at 21:02):

All of the resources should be listed on the artifacts.html page. What ones are you finding that are missing @Elliot Silver?

view this post on Zulip Elliot Silver (Sep 24 2021 at 21:02):

The IG I was looking at didn't have an artifacts page.

view this post on Zulip Lloyd McKenzie (Sep 24 2021 at 21:04):

Didn't have it, or just failed to reference it in the menu I wonder? If it's using the base template, it's going to have one. Should still be in the toc as IG authors don't have control over that (unless they completely override the template)

view this post on Zulip Elliot Silver (Sep 24 2021 at 21:04):

didn't reference it in the menu. They had a custom menu.

view this post on Zulip Elliot Silver (Sep 24 2021 at 21:05):

@Eric Haas it is in the package, but so are all the profiles, valuesets, codesystems, etc., yet we still render those.

view this post on Zulip Lloyd McKenzie (Sep 24 2021 at 21:18):

Those have information the implementer needs to see. The IG is a package and metadata. The packaged stuff is already there (in artifacts, toc and zip) and the metadata is also visible. Having the IG as a separate page "within" the IG just seems redundant. (Failure to point to the artifacts page in the menu is something we might at least want to spit out a QA warning about - feel free to submit a Git issue against the base template on that.)

view this post on Zulip Grahame Grieve (Sep 24 2021 at 21:38):

FWIW, I disagree about showing the canonical URL for the definition of the resource in the core spec. It's such a narrow interest - who cares, and why?

view this post on Zulip Elliot Silver (Sep 24 2021 at 21:49):

Wow, this is a tough crowd today. I wonder what I'm doing that's causing me to see these as issues that you aren't seeing.

view this post on Zulip Elliot Silver (Sep 24 2021 at 21:50):

OK, so if I'm filling in a StructureDefinition for a profile, what goes in baseDefinition?

view this post on Zulip Elliot Silver (Sep 24 2021 at 21:51):

Or in ElementDefinition.type.targetProfile?
Don't both of those need the core spec canonicals?

view this post on Zulip Eric Haas (Sep 24 2021 at 22:52):

I thought all you wanted was the canonical? can also get from qa.html which lists link to the page -

view this post on Zulip Grahame Grieve (Sep 24 2021 at 23:22):

The base canonicals are easily inferred and given the amount of learning needed, it's a super minor thing.

view this post on Zulip Chris Moesel (Sep 25 2021 at 00:16):

I'm with @Elliot Silver on this one. I've also wondered the same thing. I don't really see a reason not to include the canonical URL for core resources. After all, it is the only globally unique identifier for the resource. It can be easily inferred, but inference doesn't copy it into my clipboard. ;-)

view this post on Zulip Lloyd McKenzie (Sep 25 2021 at 01:52):

Throwing the 'copy canonical' and 'copy versioned canonical' hover buttons beside the resource names wouldn't be visually overwhelming and would meet the need? (It saves a bunch of typing and a possible source of transcription errors.)

view this post on Zulip Elliot Silver (Sep 25 2021 at 03:03):

I think so, although not just resources—data types too.

view this post on Zulip Eric Haas (Sep 25 2021 at 17:03):

Folks…There is a 2year old resolved tracker for this . I lodged the ticket and voiced my opposition to the hover feature which defeats the purpose. Since then I have dropped it and just find the urls directly.

view this post on Zulip Lloyd McKenzie (Sep 25 2021 at 20:01):

How does it defeat the purpose?

view this post on Zulip Elliot Silver (Sep 26 2021 at 03:41):

@Eric Haas , are you talking about J#20356?
Dropped it? As in giving up waiting for a fix to an issue filed 30 months ago that was "resolved" 18 months ago?

view this post on Zulip Elliot Silver (Sep 26 2021 at 03:55):

(And while I'm looking through old tickets, I see J#28881, which was resolved in January that agrees on the need for an IG resource page in the IG, including showing dependencies. @Jose Costa Teixeira also raised a similar issue in the template github.)


Last updated: Apr 12 2022 at 19:14 UTC