Stream: ig publishing requirements
Topic: Capability statement rendering by IG publisher
Vassil Peytchev (Dec 08 2021 at 17:17):
I have been working on some rendering enhancements for the capability statement in IGs. The initial results can be seen at https://hl7.org/fhir/uv/ipa/2022Jan/CapabilityStatement-ipa-server.html - this is rendered off the CapabilityStatement resource itself, with no -intro or -notes additional content.
Next steps before I submit a PR for the core library to incorporate this:
- add
_includeand_revincludedetails (if any) for each resource - add operation details (if any) for each resource
- add system -wide
documentandoperationdetails (if any)
Comments, concerns, and suggestions are more than welcome.
Corey Spears (Dec 08 2021 at 17:34):
This is an item that is sitting on my to do list. I have developed a script to create the narrative given and existing CapabilityStatement resource. I was going to take steps to make it easier to read and better formatted. I really like what you did here @Vassil Peytchev. I think it would be great to get it added to the core library rendering.
What are you using the render this? Does it support displaying names for artifacts that are not defined by the IG (e.g. external ImplementationGuide, CapabilityStatements, profiles)? Any opportunity to collaborate? (For any open items or Possibly including on working on an R5 version?)
Saul Kravitz (Dec 08 2021 at 17:44):
@Vassil Peytchev -- nice. Does it render the full content of the CapStmt a la @Eric Haas 's tools that are used for USCore and were adapted (as alluded to by @Corey Spears ) for mCODE, Plan-Net and CarinBB IGs?
Vassil Peytchev (Dec 08 2021 at 18:00):
The US Core rendering has been my starting point. The IPA view is created by the IG Publisher directly, using my fork of the Java org.hl7.fhir.core library. For the purposes of publishing it for this ballot cycle, I took the HTML produced by the custom IG Publisher and manually included it in CapabailityStatement.text to override the rendering of the current version of the IG Publisher.
Adding the display names is one of the details that needs to be added - I will need to learn more about what is available at the point of rendering in order to be able to do that.
Lloyd McKenzie (Dec 08 2021 at 18:28):
The rendering should incorporate the may/should/shall expectation - ideally with a summary table similar to what I currently do using XSLT. You can see the transform here and an example of what the result looks like here
Vassil Peytchev (Dec 08 2021 at 18:37):
Currently, SHOULD/SHALL/SHOULD-NOT are incorporated. Non-present expectations on included capabilities are rendered as supported.
What is the point of listing of MAY? if it is not "SHOULD-NOT" isn't anything MAY, including capabilities not explicitly listed?
Lloyd McKenzie (Dec 08 2021 at 18:38):
'MAY' is included in CapabilityStatements to say "this might be relevant and you can decide if you want to do it or not". Stuff not listed is deemed irrelevant. It's softer than a SHOULD.
Lloyd McKenzie (Dec 08 2021 at 18:39):
However, that's a design decision. From a rendering perspective, just show whatever's in the extension.
Vassil Peytchev (Dec 08 2021 at 19:00):
There is some IG authoring experience that rendering the MAYs is considered counterproductive. There is also a specific use of MAY for search parameters where not rendering the individual MAY search parameters is preferable (in the example above that is the only use of MAY at all).
Are there different considerations for server vs client capability statements with regards to MAY?
Lloyd McKenzie (Dec 08 2021 at 19:01):
If you don't want to say anything about a search parameter or function, don't. If you want to say MAY about it, then that should appear.
Eric Haas (Dec 08 2021 at 23:35):
A few observations
R S U C headers are not helpful as column labels and the table is too crowded to be useful as html. so get rid of these columns.
The blue headers and blue outlined boxes and fonts do not fit the theme of the rest of the IG narrative artifacts.
"Base System Profile" be avoided as it will only cause confusion. It is wrong to apply it here since you have no system to support but are defining expectations and cannot expect systems to use this profile as a base.
Grahame Grieve (Dec 08 2021 at 23:43):
since you have no system to support
That's not a rendering issue - the renderer should render what's in the CS. It's a design question
Eric Haas (Dec 08 2021 at 23:52):
Grahame Grieve said:
since you have no system to support
That's not a rendering issue - the renderer should render what's in the CS. It's a design question
I agree, this is not about the renderer it is about the narative generation design choices and in this case the Capstatement itself
Last updated: Apr 12 2022 at 19:14 UTC
