Stream: conformance
Topic: IG Tooling SIG
Ewout Kramer (Oct 03 2017 at 07:54):
Following up on yesterdays FHIR-I call, I promised to set up a (set of) calls aimed at authors of IG-related tooling, like IG-editors, IG-generators, IG registries etc. We'd like to discuss the intended use and scope of the current ImplementationGuide resource in relation to the build scripts of Grahame's IG builder. Questions we might look at are: what is the current intended scope? Is there a need amongst tooling authors to have a shared representation of the input to/output of IG tooling? One of the aims a flexible ecosystem of IG tools which editors can freely combine and which integrate as much as possible.
Ewout Kramer (Oct 03 2017 at 07:59):
I will post a link to a Doodle poll here. No doubt, with the timezones we're living in, this is going to be an interesting exercise, we will probably need a few voice calls to coordinate and then fall back to our regular channels.
Ewout Kramer (Oct 03 2017 at 08:04):
Doodle poll here: https://doodle.com/poll/ea7tu99cq5yd3k6v. I tried to find reasonable timeslots (>7AM <midnight) for all continents.
Grahame Grieve (Oct 03 2017 at 11:39):
we should set up a special stream for IG tooling too?
Lloyd McKenzie (Oct 03 2017 at 18:23):
I'm going to respond based on my "typical" availability - I'm traveling the next two weeks so there are a lot of slots that won't be available then.
Eric Haas (Oct 04 2017 at 01:10):
Ig-tooling and not Ig questions right?
Grahame Grieve (Oct 04 2017 at 01:18):
the json config file is in scope - it's the center of the scope
Rick Geimer (Oct 09 2017 at 19:06):
Per the Doodle poll it seems the call time is today at 5pm ET. Can someone forward me the invite? I'll be driving, but can call via my mobile phone.
Eric Haas (Oct 09 2017 at 21:52):
Was there a call - I did not get an invite?
Lloyd McKenzie (Oct 10 2017 at 03:47):
Nor did I, but I answered for general availability. Wouldn't have made today anyhow
Ewout Kramer (Oct 10 2017 at 13:32):
Per the Doodle poll it seems the call time is today at 5pm ET. Can someone forward me the invite? I'll be driving, but can call via my mobile phone.
Sorry, this was due to two things: 1) My unfamiliarity with Doodle (we normally use a Dutch version ;-), so when I picked a date, I assumed everyone would get a message - this is obviously not the case, 2) I did not see Rick on the list of participants so I did not want to go on without him.
I have added a poll with some more options - let's try this again: https://doodle.com/poll/ea7tu99cq5yd3k6v
Ewout Kramer (Oct 16 2017 at 07:45):
Thanks all for taking the time to do the poll. Monday 23rd is the one clear candidate, 22:00-23:00 CET (also known as 4-5pm EST).
Eric Haas (Oct 16 2017 at 16:40):
Are we getting an invite or should we all mark our calendeders?
Ewout Kramer (Oct 16 2017 at 18:19):
I'll look around for someone to provide a Webex or equivalent facility. I don't have this available myself....
Lloyd McKenzie (Oct 17 2017 at 00:08):
I can set one up if you like
Lloyd McKenzie (Oct 17 2017 at 00:12):
https://global.gotomeeting.com/join/230209317
Grahame Grieve (Oct 17 2017 at 01:04):
thx
Ewout Kramer (Oct 17 2017 at 07:10):
Thanks, Lloyd!
Ewout Kramer (Oct 23 2017 at 21:07):
This weeks IG tooling SIG concluded that:
- We see the value of IG resource as output of the generation process - and as input to say a registry. We might need to look at the resource to see which parts are approriate in an "output" resource
- We could see the value of an input resource to the generation process - with the intent that an author could easily switch from one tooling system to another. But is it possible?
To continue this discussion, Lloyd will draft two resources for discussion on Monday the 30th, 4pm-5pm:
- ImplementationGuideProcessInput and ImplementationGuideProcessOutput (Working titles)
Ewout Kramer (Oct 23 2017 at 21:08):
Next monday, we will use the "regular" FHIR-I call details, to make sure we're not losing @Rick Geimer and @Sean McIlvenna again ;-)
Ewout Kramer (Oct 23 2017 at 21:09):
https://global.gotomeeting.com/join/696476549
Ewout Kramer (Oct 23 2017 at 21:11):
Note: according to my worldclock website and Outlook, 4pm EST will be 21:00 CET next week, due to end of DST.
Lloyd McKenzie (Nov 03 2017 at 03:09):
The two IG variants are now up on build.fhir.org: http://build.fhir.org/implementationguideinput.html and http://build.fhir.org/implementationguideoutput.html
Jose Costa Teixeira (Nov 03 2017 at 11:46):
Good. Does it make sense to have pages contained as markup? Idea is to use implementationGuideInput to capture the text content, and not have to provide the additional pages.
Jose Costa Teixeira (Nov 03 2017 at 11:47):
perhaps it is not the intent, but I was thinking these resources would be the "packageable" stuff that is provided into and out of the IG
Lloyd McKenzie (Nov 03 2017 at 15:42):
I don't know about containing the pages directly. Perhaps it should be able to point to the location of them or reference them as Binaries. Containment means you can't maintain them independently, and I think that would be problematic.
Lloyd McKenzie (Nov 03 2017 at 15:42):
(at least if it was forced)
Jose Costa Teixeira (Nov 03 2017 at 16:53):
makes sense. I think pages should be autonomous but could also be somewhat embedded (as an option)
Jose Costa Teixeira (Nov 03 2017 at 16:53):
perhaps binary is ok and we could always contain those binaries.
Jose Costa Teixeira (Nov 03 2017 at 16:54):
my fuzzy idea is of a page that is a structured content (with title, content, links) and allows references to other parts of the resource (fhirpath?)..
Lloyd McKenzie (Nov 03 2017 at 17:48):
Including a Binary reference makes sense
Lloyd McKenzie (Nov 04 2017 at 15:46):
I've committed an update
Eric Haas (Nov 07 2017 at 15:48):
My list of generic inputs: ( I think you cover 1 and 3)
- A description of your use case
- what publishing tooling are you using
- what are your source files and
- what is your web design
Lloyd McKenzie (Nov 07 2017 at 15:51):
Well, we need to decide whether there's value to having at least some degree of consistency in the input format across tools - and if so, what degree of consistency is attainable. Personally, I think that the more we can use a common syntax, the better it will be for users as they will be less locked into a single publishing environment - and that's beneficial to everyone.
Eric Haas (Nov 07 2017 at 15:52):
as I wrote this I kind of see what you did... :-)
Eric Haas (Nov 07 2017 at 15:52):
You tried to extract the common stuff out.
Eric Haas (Nov 07 2017 at 15:53):
I do think a web design input would be useful.
Jose Costa Teixeira (Nov 07 2017 at 15:53):
what is a web design input?
Eric Haas (Nov 07 2017 at 15:54):
site map for people
Eric Haas (Nov 07 2017 at 15:55):
to show how the content fits together
Jose Costa Teixeira (Nov 07 2017 at 15:57):
ok.
Jose Costa Teixeira (Nov 07 2017 at 15:58):
me, i would hope for the IG to be able to point to binary resources like pages and images, to make it easier to package
Eric Haas (Nov 07 2017 at 15:59):
on output I would allow the pages to nest
Eric Haas (Nov 07 2017 at 15:59):
I think it does.
Eric Haas (Nov 07 2017 at 15:59):
allow for binary
Jose Costa Teixeira (Nov 07 2017 at 16:02):
ah, good point. I would like this to support things like the nesting of IGs, but i haven't figured out the requirements.
Jose Costa Teixeira (Nov 07 2017 at 16:02):
think regional/national profiles IGs and inheritance...
Lloyd McKenzie (Nov 07 2017 at 17:02):
My understanding is that the pages hierarchy reflects the site map. I don't understand the purpose of nesting the pages on output - why would tools care?
Jose Costa Teixeira (Nov 07 2017 at 17:11):
by nesting i mean across IGs
Eric Haas (Nov 07 2017 at 17:42):
My understanding is that the pages hierarchy reflects the site map. I don't understand the purpose of nesting the pages on output - why would tools care?
I'm really asking for a TOC. Why have the pages if you can't reproduce the authors intent.
Lloyd McKenzie (Nov 07 2017 at 20:23):
With the "output" version of the IG, there's no need to be able to generate a TOC. The only use of ImplementationGuideOutput is by tools - they don't need a TOC. Agree it's needed for input - and it's there.
Eric Haas (Nov 07 2017 at 21:38):
remind me of the use case for pages in output ?
Eric Haas (Nov 07 2017 at 21:38):
a tool isn't going to read the pages
John Moehrke (Nov 07 2017 at 21:56):
Output IG does need to point at top of a human readable narrative..
Eric Haas (Nov 07 2017 at 22:20):
my point is what is a tool going to do with a bunch of html pages.
Eric Haas (Nov 07 2017 at 22:21):
looking at the resource I guess I can see this as use cases:
Eric Haas (Nov 07 2017 at 22:21):
- Information necessary to support using the implementation guide for instance validation (what resources are part of the IG, what default profiles are declared and imported/contained guides)
- Information an IG authoring tool requires when refrencing a previously published IG as a dependency, including what artifacts are defined and what links are allowed.
Eric Haas (Nov 07 2017 at 22:23):
But I am still fond of the notion that you could reconstruct the IG with the output. you got all the parts, you just need the plans...
Eric Haas (Nov 07 2017 at 22:23):
...assuming is just a static web site...
John Moehrke (Nov 07 2017 at 23:03):
I would look to the output IG as having a structure that declared Actors, interactions between Actors, trigger events that cause the Actors to do something where that something might include an interaction, and alternative flows... Thus I (a conformance Validation tool) could then watch some actors and determine if they were following an IG. Thus when an Actor misbehaves, it can be shown the error...
Jose Costa Teixeira (Nov 07 2017 at 23:05):
@John Moehrke I would actually like to see this on the Input side.
John Moehrke (Nov 07 2017 at 23:05):
I forgot StructureDefinition...(message encoding)
Jose Costa Teixeira (Nov 07 2017 at 23:07):
To me the computable stuff would be on the input side, the output provides human-readable stuff along with some computable stuff (the same as or derived from the input)
John Moehrke (Nov 07 2017 at 23:08):
I am less interested in input side as it is mostly a publication process. I would expect that publication process input must be rich enough to produce the desired output.. thus I am more interested in how might the output be used, thus driving what the output must be composed of
Jose Costa Teixeira (Nov 07 2017 at 23:10):
Yes, but if the output is the result of a publishing/rendering process, I would expect the input to contain the machine-readable stuff.
Jose Costa Teixeira (Nov 07 2017 at 23:12):
I would look to the output IG as having a structure that declared Actors, interactions between Actors, trigger events that cause the Actors to do something where that something might include an interaction, and alternative flows... Thus I (a conformance Validation tool) could then watch some actors and determine if they were following an IG. Thus when an Actor misbehaves, it can be shown the error...
I would say the same but with Input instead of output.
John Moehrke (Nov 07 2017 at 23:25):
sorry... I was not disagreeing... I was just saying that I am more focused on making the output useful, where I think the input is only useful to the publication tool... Meaning I think there is a much larger audience (types of uses) for the output IG, and a very small audience (IG publishers) for the input.. mostly I am declaring my ignorance. No negative intended.
Jose Costa Teixeira (Nov 07 2017 at 23:32):
ok, i was just complementing from the "automated publishing" side. I think we want the same thing on both ends of the publisher
Lloyd McKenzie (Nov 08 2017 at 13:25):
pages in output is for validating hyperlinks in a derived IG. That's the only use-case for including pages (or image or other) in ImplementationGuideOutput.
Lloyd McKenzie (Nov 08 2017 at 13:27):
@John Moehrke Actors would be handled by CapabilityStatement instances within the IG, not by information on the IG itself. If trigger events are relevant (messaging), they'd be described in the MessageDefinition. The ImplementationGuideOutput is aimed at tools. Humans would be looking at the rendered IG.
John Moehrke (Nov 08 2017 at 14:32):
Yes, I agree that the listing of a CapabilityStatement in an IG is an indication of an Actor... Just like the listing of a StructureDefinition in an IG is an indication of a message-encoding... Very much like this model. What is missing is that today the list of these is just a bag, there is no structured way to indicate relationships between Actors and Messages; especially when a message is used in different way between different Actors. Not a huge problem today, but it becomes a problem as we write IG that are complex workflows.
John Moehrke (Nov 08 2017 at 14:33):
Note not all CapabilityStatements would be an Actor (It might be included as foundational). Not all StructureDefinitions are message-encodings (It might be foundational (common extension))
Lloyd McKenzie (Nov 08 2017 at 14:47):
Well, you can indicate who can send and who can receive messages (or invoke/have invoked RESTful operations). ExampleScenario can be used to show specific flows in terms of who talks to whom in a specific situation. But if you wanted to say A can send X to B and B can send X to C but A can't send X to C, that's not really something we support unless you go into PlanDefinition and fully define the workflow of exactly what order things occur in, etc.
Lloyd McKenzie (Nov 08 2017 at 14:47):
Message encodings would be MessageDefinitions (which would point to GraphDefinitions which point to StructureDefinitions)
Lloyd McKenzie (Nov 08 2017 at 14:48):
Not sure what a "foundational" CapabilityStatement would be...
Eric Haas (Nov 08 2017 at 18:54):
If I understand the input resource correctly - I think it makes it hard to share. If I all want to see the are completely rendered pages, I have to reconstruct them from all the includes using a tool. On the other hand, they are all there nice and pretty like in the output resource for human consumption.
Eric Haas (Nov 08 2017 at 18:55):
I understand you can just go to the IG to see them but I thought the IG resources was to make this content sharable.
Lloyd McKenzie (Nov 08 2017 at 22:46):
If you want to see completely rendered pages, you run the ImplementationGuideInput resource through the publishing process. ImplementationGuideOutput is not intended to provide a human-readable view - or a way of generating one.
Eric Haas (Nov 09 2017 at 16:50):
I understand that is not the intent but- its basically the published output. The pages and resources are here - this may be easier for some than stitching the content together using the input. Maybe we cannot neatly split input and output.
Lloyd McKenzie (Nov 09 2017 at 17:30):
The pages aren't there - just the names and anchors. There is a pointer to where the rendered version can be found, but the ImplementationGuideOutput absolutely doesn't contain the rendering.
Lloyd McKenzie (Nov 09 2017 at 17:31):
We might decide to squash Input and Output back together. The separation was so we could focus on the use-cases. And none of the usecases for ImplementationGuide so far have been about it actually containing the rendered guide.
Lloyd McKenzie (Nov 09 2017 at 17:32):
If we were to have that, it would essentially be a Bundle of Binary instances perhaps with a rule that the first Binary was the "root" page and perhaps a property for each Binary indicating the relative path to host it at.
Eric Haas (Nov 09 2017 at 17:36):
OK thanks for clarifying the contents. I was obviously barking up the wrong tree :-)
Jose Costa Teixeira (Nov 10 2017 at 07:07):
Can i put capabilityStatement as part of my IG? Will it blend?
Jose Costa Teixeira (Nov 10 2017 at 07:12):
I just tried to add one and i get "Unable to determine type for (...)capabilitystatement(...): Resource has no id in (...)
Lloyd McKenzie (Nov 10 2017 at 12:26):
I've got capability statements in most of my IGs. Sounds like a problem with your instance - do you have an id? And does it jive with your filename?
Jose Costa Teixeira (Nov 10 2017 at 16:13):
thanks. the id was actually missing and the filenames were a mess. thanks
Jose Costa Teixeira (Nov 11 2017 at 12:13):
fixed, thanks. What should a capabilityStatement look like when rendered? It just shows the narrative and it displays as ConformanceStatement (perhaps my template is outdated)
Eric Haas (Nov 13 2017 at 15:28):
Lloyd has a transform. I haven't found a suitable existing rendering for CapStatements and so I have create my own by hand based on Lloyd's transfom.
Eric Haas (Nov 13 2017 at 15:29):
thankfully only have to do this once per IG
Jose Costa Teixeira (Nov 13 2017 at 15:30):
i would be very interested in seeing that transform. Where does it live?
John Moehrke (Nov 13 2017 at 15:37):
Simplifier displays CapabilityStatements well.
Jose Costa Teixeira (Nov 13 2017 at 15:47):
ah nice. you mean this?
https://simplifier.net/IHEPDQmimplementatio/ITI-PDQmclient/~overview
Jose Costa Teixeira (Nov 13 2017 at 15:49):
@Lloyd McKenzie , is there such an XSLT for CapabilityStatements ?
Lloyd McKenzie (Nov 13 2017 at 15:56):
There is. It's in source/CapabilityStatement. It generates a narrative for you
Lloyd McKenzie (Nov 13 2017 at 15:56):
I need to move it into the Java narrative generator but haven't gotten around to it
Jose Costa Teixeira (Nov 13 2017 at 17:06):
Thanks. Btw, is there a SIG call today?
Jose Costa Teixeira (Nov 13 2017 at 18:15):
It works (i had failed to see it created not only the narrative but the entire resource)
Eric Haas (Nov 13 2017 at 18:44):
The simplifier does a nice job too.
Jose Costa Teixeira (Nov 13 2017 at 19:04):
Indeed. I am trying to hack the XSLT to work in the IG, but now the IG build is failing.
Eric Haas (Nov 13 2017 at 19:21):
Good luck with that. I would preprocess like lloyd does.
Jose Costa Teixeira (Nov 13 2017 at 19:28):
i am preprocessing (i hacked Lloyd's framework to do some additional xslts for me). But the IG builder ain't working good
Jose Costa Teixeira (Nov 13 2017 at 19:30):
(at least on my end)
Jose Costa Teixeira (Nov 13 2017 at 19:32):
[java] Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/poi/ss/usermodel/Sheet at org.hl7.fhir.r4.conformance.ProfileUtilities.generateXlsx(ProfileUtilities.java:3070)
Lloyd McKenzie (Nov 13 2017 at 19:39):
Try doing a clean
Lloyd McKenzie (Nov 13 2017 at 19:40):
It's complaining about a new library dependency, but the libraries are properly declared and Ivy should be grabbing them for you. (The main build works, so I presume that means I did things correctly...)
Jose Costa Teixeira (Nov 13 2017 at 19:40):
trying. results in 30...
Jose Costa Teixeira (Nov 13 2017 at 19:41):
same issue still :(
Lloyd McKenzie (Nov 13 2017 at 19:44):
You're running from the commandline or within Eclipse?
Jose Costa Teixeira (Nov 13 2017 at 19:48):
command line. I cannot understand Eclipse
Jose Costa Teixeira (Nov 13 2017 at 19:48):
windows command line (i cannot understand Unix :)
Lloyd McKenzie (Nov 13 2017 at 19:50):
I'm headed to the airport, but I'll do some debugging when I'm online again in a couple of hours. I tested the main build. It's possible I need to do some classpath things with the IGPublisher.
Jose Costa Teixeira (Nov 13 2017 at 19:50):
ok, thanks
Jose Costa Teixeira (Nov 13 2017 at 19:51):
is there anything I can send to assist there?
Jose Costa Teixeira (Nov 13 2017 at 19:52):
I am trying to run sdc2 IG Publisher and the same error occurs.
Jose Costa Teixeira (Nov 13 2017 at 19:52):
so doing _genonce in the sdc2 causes the same issue.
Jose Costa Teixeira (Nov 13 2017 at 19:53):
Safe and pleasant travels!
Lloyd McKenzie (Nov 13 2017 at 23:41):
Try now
Jose Costa Teixeira (Nov 14 2017 at 10:21):
Works, thanks!
Ewout Kramer (Nov 28 2017 at 11:41):
I'd like to schedule another IG SIG meeting on Monday the 11th, 4EST. Is there interest to continue the discussion where we left off before DevDays?
Eric Haas (Nov 28 2017 at 16:52):
yes
Lloyd McKenzie (Nov 28 2017 at 17:52):
y
Grahame Grieve (Nov 29 2017 at 10:42):
y
Brian Postlethwaite (Nov 30 2017 at 05:58):
I've added a new custom operation to my server that I'd be interested in some feedback from others if they thought it could be useful ;)
https://simplifier.net/sqlonfhir-stu3/load-implementation-guide
(and others thought they might consider something similar for their servers)
Christiaan Knaap (Dec 05 2017 at 07:29):
Nice idea Brian. Vonk can already load SD's from a Simplifier project (http://docs.simplifier.net/vonk/features/artifactresolution.html), so this would be a good extension of that functionality. Questions also:
- Does the operation check whether the IG is 'self supporting', and what if it depends on conformance resources outside of the IG?
- Redirecting to an OO seems unneccessarily complex to me (we don't save the OO's we generate - do others?)
Ewout Kramer (Dec 06 2017 at 10:12):
I'd like to schedule another IG SIG meeting on Monday the 11th, 4EST. Is there interest to continue the discussion where we left off before DevDays?
I just realized that I will be in a security queue at Washington DC airport at that moment. I will try to get online as soon as I have wifi.
Brian Postlethwaite (Dec 07 2017 at 07:30):
For this operation I do save the OpOoutcome, so that I know when it was done, and I can chase up later if I disconnect and go to another terminal (e.g. when I get home on my phone after kicking it off at work)
My old process used to hang around in memory, and if you called it again, it would return the result with no OpOutcome. But that doesn't help if you just want to see if it is complete, and it would restart the process.
When you start the process, it waits for a couple of seconds, and if it isn't complete, returns the current status OperationOutcome.
This will also be appropriate when I hand the generation off to another processing server (or queue the job).
Brian Postlethwaite (Dec 07 2017 at 07:31):
(planning to do the same when I handle the Bulk Data queries, that I still need to read up on)
Ewout Kramer (Dec 18 2017 at 21:23):
Hi all, we will be having our next IG Tooling SIG call on Monday the 8th of january at 4 EST.
Ewout Kramer (Dec 18 2017 at 21:24):
Subject: continue discussing splitting the current IG resource in a resource that caters for input to the IG-generation pipeline and a resource that acts as a manifest on a produced and published IG ("output")
Ewout Kramer (Jan 15 2018 at 15:13):
Hi, during last monday's call, we decided to host another IG tooling SIG meeting on Monday the 22nd of january, again at 4 EST.
Subject: make an inventorization of the inputs + input parameters into _generators_ of IGs to find commonalities - and to determine whether an ImplementationGuideInput resource would make sense at all.
Ewout Kramer (Jan 15 2018 at 15:14):
The meeting will start right after the FHIR-I meeting, so it has the same call details: just login to https://global.gotomeeting.com/join/696476549
Last updated: Apr 12 2022 at 19:14 UTC