FHIR Chat · New Errors? · IG creation

Stream: IG creation

Topic: New Errors?

Sarah Gaunt (Jan 15 2020 at 09:25):

Getting a bunch of new errors like:

eCR MessageHeader.MessageHeader.focus   error   The target profile http://hl7.org/fhir/StructureDefinition/Resource is not valid constraint on the base ([CanonicalType[http://hl7.org/fhir/StructureDefinition/Resource]])

and

eCR Organization Extension.Extension.value[x]   error   The target profile null is not valid constraint on the base ([])

Michaela Ziegler (Jan 15 2020 at 09:30):

Getting a bunch of new errors like:

eCR MessageHeader.MessageHeader.focus error The target profile http://hl7.org/fhir/StructureDefinition/Resource is not valid constraint on the base ([CanonicalType[http://hl7.org/fhir/StructureDefinition/Resource]])

and

eCR Organization Extension.Extension.value[x] error The target profile null is not valid constraint on the base ([])

I also get the error with the target profile.

Sarah Gaunt (Jan 15 2020 at 09:40):

I think @Grahame Grieve might have changed something that is causing them.

Grahame Grieve (Jan 15 2020 at 11:54):

where are you getting these?

Grahame Grieve (Jan 15 2020 at 11:54):

I mean, how can I reproduce this?

Rob Hausam (Jan 15 2020 at 14:12):

I'm getting these, too, in IPS. :(

Sarah Gaunt (Jan 15 2020 at 23:44):

I don't know how you can reproduce but all of a sudden I am getting them in eCR: http://build.fhir.org/ig/HL7/case-reporting/branches/master/qa.html#_scratch_ig-build-temp-S7TPY6_repo_source_resources_structuredefinition_ecr-messageheader

The message is:

eCR MessageHeader.MessageHeader.focus   error   The target profile http://hl7.org/fhir/StructureDefinition/Resource is not valid constraint on the base ([CanonicalType[http://hl7.org/fhir/StructureDefinition/Resource]])

I haven't changed anything (not that that means there is nothing wrong!) in that profile for ages.

The profile has:

      <element id="MessageHeader.focus">
            <path value="MessageHeader.focus"/>
            <min value="1"/>
            <max value="1"/>
            <type>
                <code value="Reference"/>
                <targetProfile value="http://hl7.org/fhir/us/ecr/StructureDefinition/ecr-task"/>
            </type>
            <mustSupport value="true"/>
        </element>

There are a few other similar ones.

Sarah Gaunt (Jan 15 2020 at 23:46):

Here is another one:

eCR Organization Extension.Extension.value[x]   error   The target profile null is not valid constraint on the base ([])

And the code:

    <element id="Extension.value[x]">
      <path value="Extension.value[x]" />
      <min value="1" />
      <type>
        <code value="Reference" />
        <targetProfile value="http://hl7.org/fhir/us/ecr/StructureDefinition/ecr-organization" />
      </type>
    </element>

Grahame Grieve (Jan 15 2020 at 23:48):

they'll go away next release

Grahame Grieve (Jan 15 2020 at 23:48):

unless they are really invalid, which is possible

Sarah Gaunt (Jan 15 2020 at 23:49):

Ok, will wait and see...

Sarah Gaunt (Jan 18 2020 at 02:50):

Have 300+ new errors in eICR and 400+ new errors in BSeR that weren't there yesterday.

Most (all?) with the following two formats:

The extension http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-trigger-code-flag-extension is not allowed to be used at this point (allowed = e:Composition.section.entry, e:Encounter.diagnosis)

Problem evaluating slicing expression for element in profile http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-composition path resource.section[3].entry[0] (fhirPath = true and resolve().conformsTo('http://hl7.org/fhir/us/odh/StructureDefinition/odh-PastOrPresentJob')): null

Sarah Gaunt (Jan 18 2020 at 03:16):

And one more:

StructureDefinition/BSeR-ReferralFeedbackComposition: StructureDefinition.snapshot.element[1].type[0]   error   The extension http://hl7.org/fhir/StructureDefinition/structuredefinition-fhir-type is not allowed to be used at this point (allowed = e:ElementDefinition.type.code)

Grahame Grieve (Jan 18 2020 at 04:46):

Is the first one right? What’s the path?

Grahame Grieve (Jan 18 2020 at 04:47):

I’ll have to debug the second

Grahame Grieve (Jan 18 2020 at 04:47):

The third - not sure what to do - the error is in the base spec

Sarah Gaunt (Jan 18 2020 at 05:28):

I don't think the first one is correct. Every single extension is coming up with the same error:

StructureDefinition/date-determined-extension: StructureDefinition.snapshot.element[1].type[0]  error   The extension http://hl7.org/fhir/StructureDefinition/structuredefinition-fhir-type is not allowed to be used at this point (allowed = e:ElementDefinition.type.code)

BSeR doesn't define any of it's own extensions and it's getting the same errors:

StructureDefinition/BSeR-Organization: StructureDefinition.snapshot.element[37].type[0] error   The extension http://hl7.org/fhir/StructureDefinition/structuredefinition-fhir-type is not allowed to be used at this point (allowed = e:ElementDefinition.type.code)

Sarah Gaunt (Jan 18 2020 at 05:29):

Oh that extension one I just pasted - that's a base spec error? It's very very similar to the pattern of the other extension errors.

Sarah Gaunt (Jan 18 2020 at 05:36):

Taking a look at this error:

Observation/observation-pregnancy-status-eve-everywoman: Observation.component[0]   error   The extension http://hl7.org/fhir/us/ecr/StructureDefinition/date-determined-extension is not allowed to be used at this point (allowed = e:Observation)

This is the xml in the example:

<component>
      <extension url="http://hl7.org/fhir/us/ecr/StructureDefinition/date-determined-extension">
         <valueDateTime value="2017-10-01"/>
      </extension>
      <code>
         <coding>
            <system value="http://loinc.org"/>
            <code value="53691-2"/>
            <display value="Gestational age Estimated from patient reported estimated date of conception"/>
         </coding>
      </code>
      <valueQuantity>
         <value value="143"/>
         <unit value="d"/>
      </valueQuantity>
   </component>

And this is the xml in the structureDefinition:

    <element id="Observation.component:sliceEstimatedGestationalAgeOfPregnancy.extension">
            <path value="Observation.component.extension"/>
            <short value="Estimated gestational age of pregnancy determination date."/>
            <definition value="Represents the date on which the estimated gestational age of pregnancy was determined."/>
            <max value="1"/>
            <type>
                <code value="Extension"/>
                <profile value="http://hl7.org/fhir/us/ecr/StructureDefinition/date-determined-extension"/>
            </type>
            <mustSupport value="true"/>
        </element>

I can't see anything wrong with it. Maybe there is something I'm missing...

Sarah Gaunt (Jan 18 2020 at 05:38):

Just realized the StructureDefinition itself is also throwing an error for each extension:

StructureDefinition/pregnancy-status-observation: StructureDefinition.snapshot.element[1].type[0]   error   The extension http://hl7.org/fhir/StructureDefinition/structuredefinition-fhir-type is not allowed to be used at this point (allowed = e:ElementDefinition.type.code)

Sarah Gaunt (Jan 18 2020 at 05:39):

I feel like if that latter error is in the base spec it's causing problems further up the stack.

Sarah Gaunt (Jan 18 2020 at 05:40):

Here are the two QA reports:
http://build.fhir.org/ig/HL7/case-reporting/branches/master/qa.html

http://build.fhir.org/ig/HL7/bser/branches/master/qa.html

Grahame Grieve (Jan 18 2020 at 09:18):

According to the definition of date-determined-extension, it can only be used on Observation. But you are using it on Observation.component. Hence the error. You need to fix up the definition of the extension if you want to use it there

Sarah Gaunt (Jan 18 2020 at 11:47):

Ohhhh... Ok will check it out tomorrow.

Sarah Gaunt (Jan 19 2020 at 02:34):

So I added the extra context and it now doesn't error on the standalone Observation. :+1:

Though I am unsure about whether I should be using "fhirpath" and "Observation.component" or "element" and "Observation.component" for the context - they seem to both do the same thing ("fhirpath" results in a few less duplicate errors in the Bundle). "fhirpath" seems like it should be more correct but none of the "official" fhir extensions that drill down to a lower level use "fhirpath", so I've used "element".

But it is still erroring on the Bundle that contains the Observation (which is just a copy and paste of the standalone Observation).

Bundle/bundle-eicr-document-pertussis-zika: resource.component[0]   error   The extension http://hl7.org/fhir/us/ecr/StructureDefinition/date-determined-extension is not allowed to be used at this point (allowed = e:Observation, e:Observation.component)

One thing that looks weird is the "e:" namespace (?) in all the paths - can't remember seeing that before?

Sarah Gaunt (Jan 19 2020 at 04:10):

Gotta say I was pretty careless with my extension.contexts... Just updated about 6 of them thanks to the new validation!

Grahame Grieve (Jan 19 2020 at 05:43):

e: means element. p: means fhirpath, x: means extension

Grahame Grieve (Jan 19 2020 at 05:43):

always use element if you can

Sarah Gaunt (Jan 19 2020 at 21:52):

Getting a crash since the last IG Pub release. It's got to be something I'm doing because nobody else is getting it, but I can't find it.

I haven't made any changes since it last worked, I just rebuilt.

Stack Dump (for debugging):                                                      (00:28.0196)
org.hl7.fhir.exceptions.FHIRException: Unable to locate the profile 'http://hl7.org/fhir/us/ecr/http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-document-bundle' in order to validate against it
    at org.hl7.fhir.r5.validation.InstanceValidator.getSpecifiedProfile(InstanceValidator.java:640)
    at org.hl7.fhir.r5.validation.InstanceValidator.validate(InstanceValidator.java:789)
    at org.hl7.fhir.igtools.publisher.Publisher.validate(Publisher.java:4194)
    at org.hl7.fhir.igtools.publisher.Publisher.validate(Publisher.java:4068)
    at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:781)
    at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:663)
    at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6861)

I defintely don't have the extra ig url on anything in my code so I must be putting in the full url somewhere the IG publisher is expecting just "StructureDefinition/eicr-document-bundle".

The places I can find "http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-document-bundle" are:

• StructureDefinition.differential.element.type.targetProfile
• StructureDefinition.url
• ImplementationGuide.definition.resource.exampleCanonical
• Bundle.meta.profile
• CapabilityStatement.rest.resource.supportedProfile
• CapabilityStatement.text.div

http://build.fhir.org/ig/HL7/case-reporting/branches/master/build.log

Rob Hausam (Jan 19 2020 at 22:22):

I had the same error, exactly as you describe. I had the "full" urls for the exampleCanonical references in the ImplementationGuide resource, and fixed it by changing them to begin with "StructureDefinition/...".

Sarah Gaunt (Jan 19 2020 at 22:32):

Hmmmm... That seems wrong. And it's definitely not the way it's shown in the example for the ImplementationGuide in the spec (https://www.hl7.org/fhir/implementationguide-example.xml.html).

I thought "canonical" was the full url. Maybe I'm getting confused (highly likely!!). Plus there's this: https://www.hl7.org/fhir/references.html#canonical

Rob Hausam (Jan 19 2020 at 22:41):

Yeah. I agree that it seems wrong for the idea of "canonical", but it does seem to be the "right" way to make it work at the moment. It is consistent with the resource references. Maybe the choice should be exampleReference, instead? (the IG resource is still FMM1)

Sarah Gaunt (Jan 19 2020 at 22:48):

@Rob Hausam agreed about getting it to work at the moment!
@Grahame Grieve can you comment?

Sarah Gaunt (Jan 19 2020 at 22:50):

Theoretially you could put a reference in exampleCanonical to, say, a US Core profile which isn't part of your IG...

Sarah Gaunt (Jan 19 2020 at 23:18):

BTW, thanks for fixing the other errors @Grahame Grieve my 350 errors from yesterday are now down to 4! (After getting it building with the exampleCanonical change above).

Grahame Grieve (Jan 20 2020 at 01:26):

so that is my bug. I'll fix it

Sarah Gaunt (Jan 20 2020 at 02:21):

I have one pesky error left:

eRSD PlanDefinition.action.trigger.data.PlanDefinition.action.trigger.data.profile  error   The target profile null is not a valid constraint on the base ([CanonicalType[http://hl7.org/fhir/StructureDefinition/StructureDefinition]])

It's doubling up on the path for some reason: "eRSD PlanDefinition.action.trigger.data.PlanDefinition.action.trigger.data.profile"

This looks a little odd too: "[CanonicalType[http://hl7.org/fhir/StructureDefinition/StructureDefinition]]" with the double StructureDefinition.

I can't see anything (obvious) wrong with the StructureDefinition: https://github.com/HL7/case-reporting/blob/master/source/resources/structuredefinition/ersd-plandefinition.xml

Sarah Gaunt (Jan 20 2020 at 20:00):

@Grahame Grieve any insights on this error - I can't figure out what is wrong with the profile.

Sarah Gaunt (Jan 20 2020 at 20:11):

so that is my bug. I'll fix it

Do we have an ETA on a fix for the exampleCanonical bug?

Grahame Grieve (Jan 20 2020 at 20:20):

I'm trying to get a clean build now so I can get it out. It's my priority

Sarah Gaunt (Jan 20 2020 at 20:35):

Thanks - sorry to keep bugging you about stuff...

Jose Costa Teixeira (Jan 20 2020 at 20:45):

@Sarah Gaunt your structureDefinition seems fine

Jose Costa Teixeira (Jan 20 2020 at 20:46):

i cannot build your IG as it is on github because it seems you have a different version of the template

Jose Costa Teixeira (Jan 20 2020 at 20:47):

This looks a little odd too: "[CanonicalType[http://hl7.org/fhir/StructureDefinition/StructureDefinition]]" with the double StructureDefinition.
I can't see anything (obvious) wrong with the StructureDefinition: https://github.com/HL7/case-reporting/blob/master/source/resources/structuredefinition/ersd-plandefinition.xml

Is this a new issue? Your structuredefinitions are in the structuredefinitions folder, so the fact that they show up as structuredefinition/structuredefinition does not scare me - unless it doesn't build..

Sarah Gaunt (Jan 20 2020 at 20:52):

Well, a new issue since Grahame released the ig publisher over the weekend...

Sarah Gaunt (Jan 20 2020 at 20:52):

Thanks for taking a look...

Sarah Gaunt (Jan 21 2020 at 20:32):

So this error has morphed into two errors wtih the latest IG publisher:

PlanDefinition.action.trigger.data.profile  error   The target profile http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-encounter is not a valid constraint on the base ([CanonicalType[http://hl7.org/fhir/StructureDefinition/StructureDefinition]])
PlanDefinition.action.trigger.data.profile  error   The target profile http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-composition is not a valid constraint on the base ([CanonicalType[http://hl7.org/fhir/StructureDefinition/StructureDefinition]])

I have changed it so many times now I can't even remember what I had originally - but I still cannot figure out what is wrong.

This is the StructureDefintion: https://github.com/HL7/case-reporting/blob/master/source/resources/structuredefinition/ersd-plandefinition.xml

And the offending xml:

<element id="PlanDefinition.action:sliceCloseOutEICR.trigger.data">
      <path value="PlanDefinition.action.trigger.data" />
      <short value="Trigger when Encounter.period.end is added." />
      <definition value="Trigger when encounter.period.end is added." />
      <min value="1" />
      <max value="1" />
      <mustSupport value="true" />
    </element>
    <element id="PlanDefinition.action:sliceCloseOutEICR.trigger.data.type">
      <path value="PlanDefinition.action.trigger.data.type" />
      <fixedCode value="Encounter" />
    </element>
    <element id="PlanDefinition.action:sliceCloseOutEICR.trigger.data.profile">
      <path value="PlanDefinition.action.trigger.data.profile" />
      <min value="1" />
      <max value="1" />
      <type>
        <code value="canonical" />
        <targetProfile value="http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-encounter" />
      </type>
      <mustSupport value="true" />
    </element>

(plus the equivalent for the other error message)

Grahame Grieve (Jan 21 2020 at 20:35):

PlanDefinition.action.trigger.data.profile is a canonical(StructureDefinition) - that is, a reference to a profile

Grahame Grieve (Jan 21 2020 at 20:36):

what you've done is said that you're replacing it with a canonical that must refer to something that conforms to an eicr-encounter

Grahame Grieve (Jan 21 2020 at 20:36):

so you want it to be an encounter, not a StructureDefinition.

Grahame Grieve (Jan 21 2020 at 20:37):

I think you want a fixed value of http://hl7.org/fhir/us/ecr/StructureDefinition/eicr-encounter, not a constraint on the target of the canonical

Sarah Gaunt (Jan 21 2020 at 20:38):

Ohhhh... Ok, will try that.

Sarah Gaunt (Jan 21 2020 at 23:31):

Thanks @Grahame Grieve - that worked. Makes so much sense once I actually see it in the code...

Richard Townley-O'Neill (Jan 28 2020 at 08:07):

Something else.
I'm using the IGPublisher ( 1.0.49) on a STU3 implementation guide and am getting the following error on dependency[0] in the output. There is no dependency element in the input file. I'm not sure whether it is new.

The extension http://hl7.org/fhir/4.0/StructureDefinition/extension-ImplementationGuide.dependsOn.packageId is not allowed to be used at this point (allowed = e:ImplementationGuide.dependsOn; this element is [[ImplementationGuide.dependency, BackboneElement])

Richard Townley-O'Neill (Jan 28 2020 at 08:09):

I think that this is an IGPublisher problem

Richard Townley-O'Neill (Jan 28 2020 at 08:45):

It is not there in v1.0.42 but is in 1.0.45

Grahame Grieve (Jan 28 2020 at 09:03):

interesting. I'll have to think about it

Richard Townley-O'Neill (Jan 28 2020 at 10:31):

The files are available https://github.com/AuDigitalHealth/ci-fhir-stu3/tree/master/output/SharedMedicinesList

Richard Townley-O'Neill (Jan 28 2020 at 10:33):

The ig.json file is called ig-sharedmedicineslist-1.json and is at https://github.com/AuDigitalHealth/ci-fhir-stu3

Sarah Gaunt (Jan 29 2020 at 00:10):

I have 197 new bad links in BSeR. I haven't changed anything - just rebuilt it today (last time was sometime last week).

Here is an example:

BSeR-ArthritisFeedbackObservation.html#/html/body/div/div/div/div/div/p/a at Line 679, column 41    error   The link 'BSeR-ArthritisFeedbackObservation.sch' for "Schematron" cannot be resolved

That Schematron link leads to a "404 Not Found" page. AFAIK, I have no control over that link or its target...

This is the link: http://build.fhir.org/ig/HL7/bser/branches/master/BSeR-ArthritisReferralSupportingInformation.sch

Sarah Gaunt (Jan 29 2020 at 00:16):

Also getting this one:

AdaptationforAdditionalReferralUseCases.html#/html/body/div/div/div/div/div/ul/li/p/strong/a at Line 144, column 17 error   The link 'StructureDefinition-BSeR-ReferralMessageHeader-definitions.html#MessageHeader.reason' for "BSeR_ReferralMessageHeader.reason" cannot be resolved

So I can see that the link has changed from this - which worked last week:
http://build.fhir.org/ig/HL7/bser/branches/master/StructureDefinition-BSeR-ReferralMessageHeader-definitions.html#MessageHeader.reason
To this - which works today:
http://build.fhir.org/ig/HL7/bser/branches/master/BSeR-ReferralMessageHeader-definitions.html#MessageHeader.reason

But why?

Do I really have to go and change all the links I manually added to the narrative??

Sarah Gaunt (Jan 29 2020 at 00:18):

I see this thread: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Changes.20to.20file.20names.3F

Which makes it sound like this change was months ago. I am so confused about all this stuff and how it is constantly changing. Having a very hard time keeping up.

Sarah Gaunt (Jan 29 2020 at 00:24):

Last week the link was:
http://build.fhir.org/ig/HL7/bser/branches/master/Patient-patient-us-core-patient-eve-everywoman.html
Today it builds to this:
http://build.fhir.org/ig/HL7/bser/branches/master/patient-us-core-patient-eve-everywoman.html

Jose Costa Teixeira (Jan 29 2020 at 00:51):

@Sarah Gaunt sounds like you have the same issue as me, but my issue was because I used a hacked template, so I was asking for it. Once I reverted to the standard templates, the issue was gone

Sarah Gaunt (Jan 29 2020 at 00:51):

But the opposite is true for the Schematron files - the link that is produced is:
http://build.fhir.org/ig/HL7/bser/branches/master/BSeR-ArthritisReferralSupportingInformation.sch
And the link that actually works is:
http://build.fhir.org/ig/HL7/bser/branches/master/StructureDefinition-BSeR-ArthritisReferralSupportingInformation.sch

Sarah Gaunt (Jan 29 2020 at 00:52):

Hmmm... @Jose Costa Teixeira I haven't hacked the template (well, not that I remember!). What did you hack?

Sarah Gaunt (Jan 29 2020 at 00:52):

Anyway - this is on the CI build. It just goes and grabs the latest template, doesn't it?

Jose Costa Teixeira (Jan 29 2020 at 00:53):

If you don't remember hacking it, then you definitely didn't.

Sarah Gaunt (Jan 29 2020 at 00:54):

Ha! That is not necessarily a true statement... But, I actually don't think I did. This IG I'm just letting the template do its thing.

Jose Costa Teixeira (Jan 29 2020 at 00:54):

hacking a template is not something we do by accident, so let me assume that.

Sarah Gaunt (Jan 29 2020 at 00:55):

Yes.

Sarah Gaunt (Jan 29 2020 at 00:55):

Plus, I made zero changes to anything between the last time it ran cleanly and today.

Sarah Gaunt (Jan 29 2020 at 01:02):

I wonder if it's got something to do with what I have on Git. Like for some reason I have a template directory there - I feel like that maybe shouldn't be there because the build goes and gets the latest version every time. But then it probably just ingores that folder anyway. Not sure.

Jose Costa Teixeira (Jan 29 2020 at 01:03):

no, the template directory is overwritten every time.

Jose Costa Teixeira (Jan 29 2020 at 01:03):

it should not matter to the build

Sarah Gaunt (Jan 29 2020 at 01:04):

Yeah, that's what I thought. It just uses what's in the input dir.
I do find it somewhat coincidental that you had the same issue yesterday...

Sarah Gaunt (Jan 29 2020 at 01:05):

Kicking myself for hitting re-build. We're supposed to be sending this IG to the TSC today for publication approval.

Jose Costa Teixeira (Jan 29 2020 at 01:06):

may be related but not the same reason. my reason is that I use custom template and I messed it up.

Jose Costa Teixeira (Jan 29 2020 at 01:06):

I'm building your IG locally to see what's up

Jose Costa Teixeira (Jan 29 2020 at 01:07):

your build runs fine over here

Jose Costa Teixeira (Jan 29 2020 at 01:08):

(except for some value sets not found)

Jose Costa Teixeira (Jan 29 2020 at 01:09):

so, suggestions:

1. delete "template" folder from your repo (this will retrigger the build)

Sarah Gaunt (Jan 29 2020 at 01:09):

Really? Well that gives me hope - you don't get the 196 bad links? I dont' get any errors - just bad links...

Jose Costa Teixeira (Jan 29 2020 at 01:09):

ah wait

Sarah Gaunt (Jan 29 2020 at 01:09):

Ok, will try that.

Jose Costa Teixeira (Jan 29 2020 at 01:09):

i did not look at qa.html

Jose Costa Teixeira (Jan 29 2020 at 01:10):

ok, sorry if I was misleading.

Jose Costa Teixeira (Jan 29 2020 at 01:10):

My issue yesterday was that the whole thing broke - the page was not navigable anymore.

Jose Costa Teixeira (Jan 29 2020 at 01:10):

you do not have that issue

Jose Costa Teixeira (Jan 29 2020 at 01:11):

you do have a lot of links that are missing indeed qa.html

Sarah Gaunt (Jan 29 2020 at 01:11):

Yeah, no errors. Just this: https://build.fhir.org/ig/HL7/bser/branches/master/qa.html

Jose Costa Teixeira (Jan 29 2020 at 01:14):

sorry if I misled you.

Sarah Gaunt (Jan 29 2020 at 01:14):

It super weird because in some cases the working link doesn't have the <ResourceType>- prefix and the published link does have it and in other cases, the working link does have the extra <ResourceType>- and the published link doesn't.

Sarah Gaunt (Jan 29 2020 at 01:14):

No problem - thanks for looking into it!

Jose Costa Teixeira (Jan 29 2020 at 01:14):

@Grahame Grieve anything in these changes could trigger this issue? somehow the resource type is added to the reference.

https://github.com/HL7/fhir-ig-publisher/commit/ef0de4db15ca2ce9ab8f4bd225a7d5a3337d7807

Sarah Gaunt (Jan 29 2020 at 01:16):

Though I guess that the ones where it isn't looking for the prefix any more are my manually added ones (which worked last week. I can fix those manually if I have to.

It's just the Schematron links that I have no control over.

Sarah Gaunt (Jan 29 2020 at 01:17):

The thing is - surely everybody using the new template would be getting bad links, not just me if it was a problem with the publisher. Though I do seem to be a problem-magnet!

Jose Costa Teixeira (Jan 29 2020 at 01:19):

you are in the front so you get all the headwind :)

Grahame Grieve (Jan 29 2020 at 01:20):

I'm going to look shortly but these sound like template issues

Sarah Gaunt (Jan 29 2020 at 01:21):

Yes, they do. But I don't think @Lloyd McKenzie has changed the template recently...

Grahame Grieve (Jan 29 2020 at 01:34):

with regard to the schematron error., this looks like @Lloyd McKenzie broke it to me. I used to generate the schematrons at 'BSeR-ArthritisFeedbackObservation.sch', but Lloyd asked me to move them to 'StructureDefinition-BSeR-ArthritisFeedbackObservation.sch' for consistency - so I did. that was about 2 months ago.

Grahame Grieve (Jan 29 2020 at 01:35):

but specifying the link is a template thing, not the IG Publisher

Sarah Gaunt (Jan 29 2020 at 01:37):

Right. Super confused. It worked last week, but not today.
I can manually remove the "StructureDefinition-" from the links on my description etc. pages, but that seems to be the opposite of adding the prefix for the Schematron.
Which wouldn't be consistent and worried I'd have to change them all back.

Grahame Grieve (Jan 29 2020 at 01:37):

you'd have to add StructureDefinition-

Sarah Gaunt (Jan 29 2020 at 01:39):

No, not for these links. That's what I'm saying. The other issue is the oppositve. I HAVE structuredefnition-, but that page doesn't exist. So I'd actually have to REMOVE the prefix.

The link 'StructureDefinition-BSeR-ReferralMessageHeader-definitions.html#MessageHeader.reason' for "BSeR_ReferralMessageHeader.reason" cannot be resolved

Lloyd McKenzie (Jan 29 2020 at 01:43):

They should be StructureDefinition-BSeR.... The template I have locally expects them to be there. I don't know why the template that's checked in doesn't. It must be something that got messed up during the roll-back. I expect to roll forward (with Sean's permission) shortly. We'll see if that fixes things.

Grahame Grieve (Jan 29 2020 at 01:44):

looks like a package problem - what is committed is <p>Other representations of profile: <a href="{{[type]}}-{{[id]}}.sch">Schematron</a>

Sarah Gaunt (Jan 29 2020 at 01:44):

Please don't roll forward until after BSeR is published.
But could you just fix that one thing, because I can't publish with broken links.

Grahame Grieve (Jan 29 2020 at 01:45):

what is in the package

Grahame Grieve (Jan 29 2020 at 01:45):

<p>Other representations of profile: <a href="{{[id]}}.sch">Schematron</a>

Sarah Gaunt (Jan 29 2020 at 01:51):

Unless you roll forward but add some functionality to allow me point to an earlier version of the template...

Lloyd McKenzie (Jan 29 2020 at 01:54):

Pointing to an earlier version of the template isn't currently possible (and not sure if it will be). If Trifolia works with the new template, what's the concern about rolling forward?

Grahame Grieve (Jan 29 2020 at 01:56):

Sarah doesn't want you to break anything. and you've been rolling backwards and forwards a bit...

Sarah Gaunt (Jan 29 2020 at 01:57):

I'm not using Trifolia - I'm using your template though. This IG uses the current version of the template. It has gone through workgroup and FMG approval for publication. If you change the template you will break the IG as it currently is. TSC hasn't yet approved it and it will then need to be published.

Sarah Gaunt (Jan 29 2020 at 01:58):

So the question is - how do we manage the long publication process with everything changing all the time?

Sarah Gaunt (Jan 29 2020 at 01:58):

Shoud I constantly re-build and change stuff in an IG that was working last week?

Sarah Gaunt (Jan 29 2020 at 02:00):

Also - in terms of approval. If we (well, just me) are really splitting hairs. The committees approved the IG looking a certain way. Who is to say that changing the template doesn't change something that nobody notices and then we are actually publishing an IG that hasn't been properly approved /checked. Probably not explaining that very well, but hopefully it makes sense.

Grahame Grieve (Jan 29 2020 at 02:01):

I don't think we;re talking about changing look and feel?

Sarah Gaunt (Jan 29 2020 at 02:02):

No, I know (I'm just saying). The real issue is that AGES to get through all the approvals. How many times can I be expected to re-build and update an IG that was workign fine at the beginning of the process?

Sarah Gaunt (Jan 29 2020 at 02:04):

I actually assumed I was finished with BSeR last week. And then I re-ran it this morning, just to check. And now I've spent more time, trying to get to the bottom of what is wrong. I know things like this are going to happen, but if we could just minimize them at all possible...

Sarah Gaunt (Jan 29 2020 at 02:08):

And it is a possibility that changing the template could break something that nobody notices until an IG has been published. Because there is essentially no QA other than us and the workgroups etc, looking at the IG. So if something changes and then it goes straight to publication, it could happen. Might be a remote possibility, but it's not impossible.

Grahame Grieve (Jan 29 2020 at 02:09):

mostly the changes correspond to me picking something up that is a problem and adding rules for them

Sarah Gaunt (Jan 29 2020 at 02:09):

That's the IG publisher - not the template.

Sarah Gaunt (Jan 29 2020 at 02:09):

The IG publisher makes it very known when things are broken! :-P

Sarah Gaunt (Jan 29 2020 at 02:11):

Anyway, just saying. It sure would be nice to be able to pick a previous version of the template to use if there are going to be changes.

Grahame Grieve (Jan 29 2020 at 02:13):

actually, you can. you can nominate the version of the template - it's just a package. Only in this case, I don't think that there's any previous version to depend on since Lloyd hasn't done any versioning

Sarah Gaunt (Jan 29 2020 at 02:18):

THAT's exactly what we need!

Sarah Gaunt (Jan 29 2020 at 02:19):

But coudlnt you start versioning now?

Grahame Grieve (Jan 29 2020 at 02:20):

unfortunately no. the versioning infrastructure is broken for templates. I just realised. I',m working on that too

Grahame Grieve (Jan 29 2020 at 02:21):

but.. good news... I think...

Grahame Grieve (Jan 29 2020 at 02:23):

you should get a good build if you do it now

Grahame Grieve (Jan 29 2020 at 02:26):

somehow there was a bad build of one of the templates

Sarah Gaunt (Jan 29 2020 at 02:31):

Yay! You fixed it! Thankyou!! (See I definitely AM a problem-magnet - why didn't anybody else have a problem???)

Grahame Grieve (Jan 29 2020 at 02:35):

a couple of people reported it to me yesterday, I just didn't get to it

Grahame Grieve (Jan 29 2020 at 02:36):

you might decide that the forthcoming IGPublisher will give you problems to fix. It won't create any new messages, but will give you much more info about the ones you already have

Sarah Gaunt (Jan 29 2020 at 02:36):

Ok - that makes me feel better.

Sarah Gaunt (Jan 29 2020 at 02:36):

Ok, will check it out.

Jose Costa Teixeira (Jan 29 2020 at 02:40):

From a related discussion - would be good to point to a specific version of the ig template and of the publisher

Jose Costa Teixeira (Jan 29 2020 at 02:40):

But at some point we should have something that will not change

Jose Costa Teixeira (Jan 29 2020 at 02:40):

Some of us just want to work on the
Dev version

Grahame Grieve (Jan 29 2020 at 02:41):

well, you can point to a specific version of the publisher, but the CI build will always use the current one. Also, old IG publishers have a habit of not running due to server dependencies

Jose Costa Teixeira (Jan 29 2020 at 02:42):

Where to point to a specific version of the publisher?

Grahame Grieve (Jan 29 2020 at 02:42):

and I'm simply not interested in supporting old versions of the publisher. My first response will always be, it's only an issue if it's current

Sarah Gaunt (Jan 29 2020 at 02:42):

Yeah, I pretty much only use the CI build as I can't handle how much my machine slows down if I run locally.

Grahame Grieve (Jan 29 2020 at 02:42):

all IG publishers are released through maven, so you just get the version you want from maven

Grahame Grieve (Jan 29 2020 at 02:43):

the trade off for running the current ig publisher is that I generally fix issues same day...

Sarah Gaunt (Jan 29 2020 at 02:43):

@Lloyd McKenzie I've negotiated with @Sean McIlvenna and you can release the new version of the template. He's going to fix up BSeR while I sleep and we'll hold off sending to TSC until it works again tomorrow...

Jose Costa Teixeira (Jan 29 2020 at 02:49):

it's only an issue if it's current

I think that's more than adequate

Sarah Gaunt (Jan 29 2020 at 02:52):

@Lloyd McKenzie please just give me 30min notice on the new release if it happens in the next few hours...

Grahame Grieve (Jan 29 2020 at 02:57):

it just happened

Sarah Gaunt (Jan 29 2020 at 02:59):

I know, I saw - I was just about to hit push on my commit. Phew...

Lloyd McKenzie (Jan 29 2020 at 03:06):

The new version is now pushed - and it has a distinct version number (now up to 0.0.2).

Sarah Gaunt (Jan 29 2020 at 23:05):

So now with the new template / new publisher - there are 63 new warnings on BSeR - they are all the same and none of them say which resource has an issue:

warning Unable to find description for the resource. Descriptions are strongly encouraged to allow proper population of the artifact list.

Any ideas, @Lloyd McKenzie or @Grahame Grieve

Grahame Grieve (Jan 29 2020 at 23:06):

that'll be from the template

Grahame Grieve (Jan 29 2020 at 23:07):

it's wanting you to fill out http://hl7.org/fhir/implementationguide-definitions.html#ImplementationGuide.definition.resource.description

Sarah Gaunt (Jan 29 2020 at 23:07):

Ok. I can see on the artifact page which don't have descriptions, but something saying which ones in the QA would be super-helpful.

Sarah Gaunt (Jan 29 2020 at 23:08):

Yeah, I know what it means, it's just not super useful having a long list of warnings without saying WHICH resource is affected.

Sarah Gaunt (Jan 29 2020 at 23:10):

Doesn't it take the resource description from the actual resource if there's nothing in the ig?

Sarah Gaunt (Jan 29 2020 at 23:12):

Oh, must be all the examples.

Lloyd McKenzie (Jan 30 2020 at 01:55):

It'll probably be the examples. They don't have names or descriptions when you expect the publisher to grab them magically, so it's best to at least enumerate those. I'm sorry for not spitting out more context in the message. I'll try to fix that soon.

Lloyd McKenzie (Jan 30 2020 at 01:56):

@Grahame Grieve Do we need to increment the version number for a minor change like that (which means incrementing the version number on all dependencies), or can we get away with only doing that for changes that affect inputs, outputs or validation logic?

Grahame Grieve (Jan 30 2020 at 02:07):

the version number is nominal right now. there's no release cycle yet. Soon...

Mark Kramer (Jan 30 2020 at 02:21):

I think some controls and constraints need to be placed on IG publishing tools. Maybe we should have formal reviews before new templates are dropped on our heads. This process is not a process, lacks standard operating procedures, quality processes, and is OUT OF CONTROL!

Lloyd McKenzie (Jan 30 2020 at 02:21):

To confirm, no need to increment version number (for now) when just correcting an error message to be more expressive?

Lloyd McKenzie (Jan 30 2020 at 02:33):

Mark, the challenge, as always, is limited resources. When IGs aren't publishing correctly, are reporting spurious error messages or are failing, those impacted want the fixes "ASAP". When the fixes are made and impact others, the message is to slow down. The number of people who could conduct a meaningful review is quite limited, generally in different time-zones and are all very busy. Adding additional processes will slow things down and may keep content from publishing on proposed timelines, or with lower quality. The reality is that the IGPublishing stack is still not terribly mature. We're at a similar place to where we were with the core publisher a couple of years ago. As the mechanisms stabilize (which has required time for us to discover what was even needed/desired), the tooling should stabilize as well - and more rigorous change processes might be feasible. (Though we still haven't introduced those for the core publication - perhaps because changes are so much less common.) The template machinery was introduced "just in time" in September and, by my evaluation, would still be in "Alpha" state. Yes, breaking changes are annoying, but they should be expected.

Note that with the newest publishing machinery, you can update to the new publisher only when you're ready (though you do need to use the newest publisher when going for official publication or using the CI build). It should also be possible to lock your publication to a specific version of the template, though again the expectation is that official publications will use the most recent release. (If the most recent release is profoundly broken, obviously we'd relax that requirement.)

I'm also not trying to shut down discussion on process improvements. If we can figure out something that provides a meaningful difference in the experience of IG publishers, doesn't have a significant negative impact on response time and can be managed with our existing pool of contributors, we should absolutely take a look at it. I don't see any obvious solutions, but that doesn't mean that there aren't any.

Mark Kramer (Jan 30 2020 at 02:37):

Lloyd, there is certainly truth in what you say about limited resources, but you are not approaching this in a sound software engineering manner. You are flinging out code changes that are breaking IGs right and left. I feel for the level of effort you are putting in. But this cannot continue.

Lloyd McKenzie (Jan 30 2020 at 02:41):

The door is open for a concrete alternative proposal. The reality is we're in a position where the organization has little choice but to rely on "alpha" code. Expecting the platform to behave in a stable production manner is unrealistic.

Mark Kramer (Jan 30 2020 at 02:44):

Let's work on it. There are professional software development practices that have been developed to avoid this type of problem. We embrace quality practices elsewhere in HL7, but not here. The lack of process is driving IG developers to tears and anger. This cannot continue.

Lloyd McKenzie (Jan 30 2020 at 02:48):

One change we could institute is a 1 day waiting period between changes being pushed to base and when they're pushed to the derived templates. That would give IG authors a chance to experiment with the new version to see if there ar issues. We might even be able to auto check some of the most recently published successful ci builds against the new template to see if there are any unexpected impacts. (And to ensure that expected impacts are properly highlighted.)

Mark Kramer (Jan 30 2020 at 02:52):

That is an idea. Let's think more about moving deliberately between working versions, with adequate migration time, notification, communication, regression tests, version control, and the same assurances the rest of the software world uses.

Lloyd McKenzie (Jan 30 2020 at 02:57):

Regression tests are hard in this space. Publishing an IG takes a significant chunk of time and any change to any of the headers and footers makes automated comparison hard and creates a huge amount of work to maintain. Keep in mind that whatever process we're using should be tuned for an alpha environment with high-frequency change.

Mark Kramer (Jan 30 2020 at 03:01):

Let's work together to find something that works better for you and the IG community, that takes into account the constraints and pressures we all feel.

Grahame Grieve (Jan 30 2020 at 04:45):

so the IG publisher itself is fairly mature now. I'm mostly making fixes in the validator, and it's picking up new quality issues left and right, but publishing has been pretty solid since the technical correction - which we knew was going to be a process disaster.(I think there's been one break since then).

Now the template is going through rapid change as it settles. What we need is version control over the template. The problem is that my scheme for version controlling the template depends on an external resource that I can't bring into line under my control - that is, packages.fhir.org

Grahame Grieve (Jan 30 2020 at 04:47):

switching to using packages.fhir.org itself will introduce instability into the system as we refine the processes associated with that, but I'm keen to get to that as soon as the current development issues are resolved. It's just taking a long time to get them resolved

Mark Kramer (Jan 30 2020 at 12:22):

I would like to schedule an IG Creators Birds of a Feather at Sydney to discuss these issues. Would that be productive? What evening could that take place?

Sarah Gaunt (Jan 30 2020 at 12:31):

I think it could be very productive. I haven't had time to even consider schedule yet. Will look tomorrow morning. Maybe Sunday?

Mark Kramer (Jan 30 2020 at 12:33):

That's the first day of the Connectathon (everything is shifted +1 day). We can work on it then, but it would be smart to engage openly during the WG meeting in a Q5 or Q6 official Birds of Feather.

Rick Geimer (Jan 30 2020 at 15:07):

I agree, I'm up for a Q5/Q6 discussion on this in Sydney. It is extremely frustrating not only to those working on IGs, but to all project managers, stakeholders, etc. when an IG developer says "zero errors and warnings, ready for HL7 approvals", then suddenly everything is broken the next morning. There needs to be some predictability to the process.

Jose Costa Teixeira (Jan 30 2020 at 16:05):

The door is open for a concrete alternative proposal. The reality is we're in a position where the organization has little choice but to rely on "alpha" code. Expecting the platform to behave in a stable production manner is unrealistic.

This discussion seems to be much about the complaints we get "this was working yesterday, now it's broken".
1. Grahame points to version control of the IG templates and once that's in, i think all those complaints are removed - we will have predictability. If i use a specific version, what was working yesterday stays working today (and what was broken yesterday is still broken today because we have one development branch) .

Chris Moesel (Jan 30 2020 at 16:17):

Grahame points to version control of the IG templates and once that's in, i think all those complaints are removed - we will have predictability.

If the auto-build respects requests to use older versions of the publisher and older versions of the templates, then yes. If it forces the newest versions (as I think it does now), then there is still some risk w/ the autobuild; and autobuild is the only allowed way for producing official IGs for ballot/publication.

Jose Costa Teixeira (Jan 30 2020 at 16:18):

2. Implement an extremely lightweight change process (Jira-based, although for some of us Jira-based and lightweight are not concurrent terms), where we can park the needed changes (insteaf of only zulip) and check them as done. This is extremely useful also in documenting the changes.

Jose Costa Teixeira (Jan 30 2020 at 16:20):

@Chris Moesel yes, I assume this is easy once we get the template to be able to point to a specific version

Jose Costa Teixeira (Jan 30 2020 at 16:21):

So, I think we have 2 options:

1. The IG points to a specific version of the template, and that version of the template points to a specific version of the Publisher
2. The IG points to a specific version of the template and to a specific version of the publisher

Jose Costa Teixeira (Jan 30 2020 at 16:21):

option 1 feels safer

Grahame Grieve (Jan 30 2020 at 18:46):

suddenly everything is broken the next morning

This is effectively saying, I would rather not know what is wrong and go ahead anyway. And I also want FMG to ignore what is potentially wrong as well and not ask.

Grahame Grieve (Jan 30 2020 at 18:51):

this is predicated on the fact that most of the changes that happen to the publisher are bug fixes and validation improvements. The actual IG publication is stable.

Rick Geimer (Jan 30 2020 at 19:22):

I disagree. There needs to be some way of discovering that something is ready for the work group and FMG at the time you fill out the publication request, and having that be stable. If I have zero errors and warnings at that time, and then the morning (or even an hour before) FMG review a change is made that suddenly results in a bunch of new issues (even if they are validation improvements) then that is very problematic from the perspective of those developing IGs, and any project plans, etc. that depend on it.

Grahame Grieve (Jan 30 2020 at 19:23):

which bit do you disagree with? You prefer to be in ignorance?

Lloyd McKenzie (Jan 30 2020 at 20:51):

If there are problems, there are problems. If it's necessary to publish without fixing the issues, the FMG can approve that (and has in the past). However, if there aren't pressing reasons to publish right away (e.g. ballot deadline, rulemaking deadline), then yes it's possible you might think you're done only to discover at the last minute that there's a few days more work because you're suddenly aware of problems you didn't know about before.

I think the default for the CI build should always be "current publisher, current template". I also think that should be the default expectation for publishing. However, I think it should be possible in the ig.ini to point to a prior template and/or publisher and use that instead. Doing so should automatically spit warnings out in the qa.html. The project would need to convince the FMG or the publication manager (i.e. Lynn/Grahame) why using the latest and greatest isn't possible/appropriate. (There may be some situations where either the template or publisher are actually broken, meaning they can't be used. In other cases, the amount of effort to support the latest version might be unreasonable due to pressing timelines. If neither of those apply, then the expectation would be to do the work, even if it means publishing a few days later than planned.

One candidate for the BoF would be Tuesday lunch (our normal Monday lunch session). My plan had been to go over Jira and template plans and issues, and this would certainly fall into that category.

Grahame Grieve (Jan 30 2020 at 20:54):

when FMG is approving, if the IG wasn't being built with the latest IG publisher, I would certainly build it with the latest IG publisher and compare issues. So either way, you'll be comparing issues.

Grahame Grieve (Jan 30 2020 at 20:54):

and asking FMG for approval

Grahame Grieve (Jan 30 2020 at 20:54):

I think the situation is different with templates

Sarah Gaunt (Jan 30 2020 at 21:31):

The situation is definitely different with templates.

I'm actually not so much worried about seeing more issues with my IG when I re-build again.

It's the having to work through, say 400 errors that weren't there yesterday and aren't actually issues with the IG but are issues with the publisher that can be a bit of a problem (and yes, @Grahame Grieve is awesome at getting those fixes as quickly as possible), but it also takes a significant amount of time to work through and let Grahame know what the issues are - i.e. trying to figure out if they are my IG issues or just an issue with the IG publisher.

I am fine with fixing any *actual * errors in my IG.

The biggest thing (for me) over the past couple of weeks has been the template release with no warning which immediately broke, as in totally crashed my IG build. On the morning before the day we were to get a phase of the publication approval.

Plus, and I agree that it's probably a very slight chance, I think that a new release of the template could potentially break things in the IG that might never get noticed until after publication. And if one is in the middle of the publication process when a new template is dropped, it could be an issue. Pointing to an earlier known working version of the template would solve all of that.

Sarah Gaunt (Jan 30 2020 at 21:34):

For the IG publisher, maybe a dev version re-build of say, the IGs that have been built in the past 6 months (or some other time frame) before release and if there is a massive jump in errors or bad links, maybe a bit more testing is warranted? Or even just checking to see if there are a bunch of errors that weren't there before, and aren't the new warnings/errors that are expected with the new validation code?

Sarah Gaunt (Jan 30 2020 at 21:37):

Tuesday lunch sounds good.

Grahame Grieve (Jan 30 2020 at 21:40):

we do actually have test IGs but maintaining them has proven too time-consuming. (unlike the test cases for validation and snapshot generation which are the foundation on which the stability we do have is built on)

Sarah Gaunt (Jan 30 2020 at 21:42):

Yes, I can imagine. What about just usingthe actual existing (recent) ones?

Sarah Gaunt (Jan 30 2020 at 21:42):

It definitely wouldn't be perfect, but a quick delta between validation before and after might be useful?

Jose Costa Teixeira (Jan 30 2020 at 21:44):

+1 for Tuesday lunch

Grahame Grieve (Jan 30 2020 at 21:45):

so the process would be:

for the last X IGs built in on the CI-Build:

• git clone the repository
• build the IG
• compare the count of errors with the last on the CI-build
• review the grounds for any differences

Not clear how much of that is automatable

Jose Costa Teixeira (Jan 30 2020 at 21:45):

I think using the last X could be the canary in the coal mine, but not much more than that

Sarah Gaunt (Jan 30 2020 at 21:48):

Yes, something like that. I'm sort of thinking that if there is a big jump in the count it would warrant a check. And that last bullet would definitely be manual. And probably you! Though, I'd also be fine looking into issues. Like if one of my IGs has a big jump, let me know, I can help debug. Better than desperately trying to figure it out when it goes live!

Sarah Gaunt (Jan 30 2020 at 21:54):

suddenly everything is broken the next morning

This is effectively saying, I would rather not know what is wrong and go ahead anyway. And I also want FMG to ignore what is potentially wrong as well and not ask.

Not to speak for @Rick Geimer (but he's probably on his 14 hour flight by now - did I mention my flight is only an hour?! ha!), but I think he's probably more talking about what I was mentioning - the times where the IG is broken, but they aren't actually issues with the IG, but are issues with the publisher.

Jose Costa Teixeira (Jan 30 2020 at 22:03):

I think some other automated flow will be inevitable, so why not that?

Sarah Gaunt (Jan 30 2020 at 22:07):

For sure! Automation always makes me happy...

Grahame Grieve (Jan 30 2020 at 22:20):

so why not that

why not what?

Jose Costa Teixeira (Jan 30 2020 at 22:22):

Why not design an automatable solution, even if using a test ig, instead of looking at what we can do with a sample of igs, then do manual work...

Grahame Grieve (Jan 30 2020 at 22:26):

well, there's a bunch of test IGs and they have JUnits associated with them. I just can't maintain them.

Grahame Grieve (Jan 30 2020 at 22:29):

just to be clear: I spend about 80%of my time supporting the validator and the publisher, which we provide for free. I cannot afford to do that - either financially or practically (I have some support from US Govt for it, but not as much as it needs). So I don't have time to invest in the testing we're talking about here

Jose Costa Teixeira (Jan 30 2020 at 22:36):

That is my point - we either find a way to get this off your back (including maintaining the test igs) or people's first reaction to any issue will be @ mentioning you, which is not good

Grahame Grieve (Jan 30 2020 at 22:40):

well, @Mark Iantorno will be gradually picking up the work - that's one thing we've picked up, and a lot of that focus will be on quality

Sarah Gaunt (Jan 30 2020 at 22:40):

Exactly. I didn't realize you were doing so much for free. This seems like maybe something that we can be getting other people to help with?

Sarah Gaunt (Jan 30 2020 at 22:41):

Well, that's good. I think @Sean McIlvenna has also expressed interest in helping out?

Grahame Grieve (Jan 30 2020 at 22:41):

unfortunately very often other people doing the work increases my work load. At least initially, for ure

Sarah Gaunt (Jan 30 2020 at 22:42):

Oh, I hear you and know EXACTLY what you mean... One of my biggest problems - you're damned if you do and damned if you don't!!

Grahame Grieve (Jan 30 2020 at 23:36):

also, for those reading this thead.. the IG Publisher is a system, not a standalone piece of software. In addition to the IG publisher, publishing also uses:

• the packaging distibution system
• the packages for the core spec
• the current build infrastructure (whether you are current build or not)
• tx.fhir.org
• test.fhir.org

Lloyd McKenzie (Jan 31 2020 at 02:39):

And the templates. And failures with any one of those can result in failures in the build itself (both visible in qa.html and not)

Lloyd McKenzie (Jan 31 2020 at 02:41):

I'm not sure about "last n" because that ends up being pretty random. It might be better to identify specific IGs which are known to be 'entertaining' and, so long as they've built successfully on the current CI-build, build them with the new version and generate a diff of the qa.txt files.

Grahame Grieve (Jan 31 2020 at 03:01):

a static list of IGs isn't so hard.... do we have a set of IGs to list?

Lloyd McKenzie (Jan 31 2020 at 03:14):

I figured you'd be in the best position to nominate the "most interesting". IPS for sure. Not sure what else?

Grahame Grieve (Jan 31 2020 at 03:16):

my list: SDC IPS ECR us-core au-base + the 3 main templates

Lloyd McKenzie (Jan 31 2020 at 03:38):

Would there be a mechanism to allow release of a template and testing with those without it impacting anyone else? Or would every IG have to hard-code to a specific template version and just get a warning if they're not using 'current'?

Grahame Grieve (Jan 31 2020 at 03:39):

testing templates is harder. let me think about

Jose Costa Teixeira (Jan 31 2020 at 04:16):

I think we could use the same mechanism, and just use 'alpha' or 'preview' templates
Thus:

1. By default all igs get 'current' template version
2. IG editors could explicitly use another template version
   2.1 conservative or production publication uses version 'stable' or '0.0.2'
   2.2 bold users/reviewers can point to 'alpha' version of template
   2.3 the automated testing (and template maintainer) can even use a 'SecretTemplateVersionJust4Lloyd'

Jose Costa Teixeira (Jan 31 2020 at 04:19):

Happy to see a stable list of igs instead of a random list. In future I think we should list the IG features and simply make sure we cover all of them

Jose Costa Teixeira (Jan 31 2020 at 04:44):

Features :

• XHTML/ Markdown
• each of the layouts - profiles / Logical models / valuesets...
• Profiles with / without examples
• Derived templates
• OpenAPI
• Active Tables
• With and without inherited invariants
  ...
  (for which I was really happy to see just even a small note in the commit to keep track of those)

Jose Costa Teixeira (Jan 31 2020 at 04:49):

Another approach to the whole thing would be feature toggle, but I don't think it is the most adequate here.

Sarah Gaunt (Jan 31 2020 at 05:21):

Add BSeR - has nested bundles which were challenging...

Grahame Grieve (Jan 31 2020 at 05:46):

well, I set it up on my machine - 3 templates + USCore, AUBase, SDC ECR IPS MHD - it take s15minutes to run all of that. I'll think about how to make it portable (lots of reasons why it's not portable right now)

Grahame Grieve (Jan 31 2020 at 08:51):

https://github.com/FHIR/fhir-ig-test-record

Lloyd McKenzie (Jan 31 2020 at 09:00):

Should we just be checking counts or should we be doing an actual diff of the errors and warnings found and seeing what's different (whether more or less - as either could be a problem)

Grahame Grieve (Jan 31 2020 at 09:02):

the unit tests check the counts. Anything more is manual check - probably a diff on qa.txt between current and [current-ver] is the easiest

Jose Costa Teixeira (Jan 31 2020 at 10:22):

It seems that this steps relies on one thing that is perhaps obvious, but not for me:
(How will we tell an IG to use a specific version of the template, and a specific version of the publisher ?

Grahame Grieve (Jan 31 2020 at 19:08):

you can't, right now.

Sarah Gaunt (Feb 02 2020 at 00:48):

Did we decide on a time when we are going to discuss release processes? Are we locked in for Tuesday lunch?

Lloyd McKenzie (Feb 02 2020 at 01:04):

We will certainly have some discussion in that timeslot. I'm open to discussion beyond that too. (I don't want to use the whole of Mon. lunch for that topic as there are other things we need to talk about too.)

Sarah Gaunt (Feb 02 2020 at 05:52):

Mon lunch? Or Tues lunch? Confused!

Lloyd McKenzie (Feb 02 2020 at 10:10):

Sorry. "The normal Monday lunch session that we have shifted to Tuesday for Australian cultural reasons" :)

Grahame Grieve (Feb 02 2020 at 10:55):

we're all day confused here

Grahame Grieve (Feb 02 2020 at 12:41):

ok, I'm just releasing a new IGPublisher that makes versioning work for templates. The way it works is that if you nominate a package for the template e.g.

[IG]
template=hl7.fhir.template

Then you can now specify a version like so:

[IG]
template=hl7.fhir.template#0.0.5

if you don't specify a version, that means 'current' - whatever is in github that the authors are playing with.

Grahame Grieve (Feb 02 2020 at 12:41):

tomorrow I'll set up a history page so you can see the latest versions of the templates

Grahame Grieve (Feb 02 2020 at 19:12):

done:

• http://fhir.org/templates/fhir.base.template/history.html
• http://fhir.org/templates/hl7.base.template/history.html
• http://fhir.org/templates/hl7.fhir.template/history.html

Grahame Grieve (Feb 02 2020 at 19:12):

though most of you will only need http://fhir.org/templates/hl7.fhir.template/history.html

Sarah Gaunt (Feb 02 2020 at 22:48):

Nice! Thanks @Grahame Grieve !

Rick Geimer (Feb 03 2020 at 03:58):

Agreed, thanks Grahame. @Sean McIlvenna Let's see if we can work template versioning into Trifolia in the near future so we can fall back to an older template if needed. Would be nice to have a GUI option to select from a list of available templates.

Grahame Grieve (Feb 03 2020 at 04:10):

http://fhir.org/templates/hl7.fhir.template/package-list.json if you want a parseable list

Chris Moesel (Feb 03 2020 at 17:55):

@Grahame Grieve and @Lloyd McKenzie -- I think there might be something that isn't working correctly w/ the new IG Publisher and template versioning. I noticed that the fhir-shorthand documentation was down and saw that the auto-build failed. It seems it is failing for others as well.

The build log says:

Load Template from hl7.fhir.template#current                                     (00:01.0460)
Installing hl7.fhir.template#current to the package cache
  Fetching:
  Installing:  done.
 Load Template from hl7.base.template#0.0.1                                      (00:01.0509)
Publishing Content Failed: Unable to find the package source for 'hl7.base.template#0.0.1' at http://fhir.org/templates/fhir.base.template/0.0.1/package.tgz (00:01.0621)
                                                                                 (00:01.0622)
Use -? to get command line help                                                  (00:01.0622)
                                                                                 (00:01.0622)
Stack Dump (for debugging):                                                      (00:01.0622)
org.hl7.fhir.exceptions.FHIRException: Unable to find the package source for 'hl7.base.template#0.0.1' at http://fhir.org/templates/fhir.base.template/0.0.1/package.tgz
    at org.hl7.fhir.utilities.cache.PackageCacheManager.loadPackage(PackageCacheManager.java:708)
    at org.hl7.fhir.igtools.templates.TemplateManager.loadPackage(TemplateManager.java:219)
    at org.hl7.fhir.igtools.templates.TemplateManager.installTemplate(TemplateManager.java:87)
    at org.hl7.fhir.igtools.templates.TemplateManager.installTemplate(TemplateManager.java:101)
    at org.hl7.fhir.igtools.templates.TemplateManager.loadTemplate(TemplateManager.java:73)
    at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1263)
    at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1204)
    at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:659)
    at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6937)

I noticed that even though we asked (in ig.ini) for hl7.fhir.template#current, the error happens trying to resolve hl7.base.template#0.0.1. I'm guessing it's trying to resolve hl7.base.template#0.0.1 because that must be what hl7.fhir.template is based on. So that may be fine (and expected).

But I also noticed that even though it is trying to resolve hl7.base.template#0.0.1, the error message indicates it is looking for it at http://fhir.org/templates/fhir.base.template/0.0.1/package.tgz. Note that the path contains fhir.base.template, instead of the expected hl7.base.template. I suspect that perhaps this is at the root of the problem? Either that or v0.0.1 of that template does not really exist.

I was able to reproduce this locally and temporarily fix it by switching our template from hl7.fhir.template to hl7.base.template (which actually does resolve fine for v0.0.2).

Chris Moesel (Feb 03 2020 at 18:04):

Quick update: I temporarily switched fhir-shorthand to hl7.base.template and although it fixed the original problem, now it is failing with a different one (on autobuild only, works locally). I see that other IGs are failing on this problem too:

IG template is not trusted.  No scripts will be executed                         (00:01.0876)
Publishing Content Failed: Unable to execute 'onLoad' in script 'scripts/ant.xml' as the script is not trusted (00:02.0534)
                                                                                 (00:02.0534)
Use -? to get command line help                                                  (00:02.0535)
                                                                                 (00:02.0535)
Stack Dump (for debugging):                                                      (00:02.0535)
org.hl7.fhir.exceptions.FHIRException: Unable to execute 'onLoad' in script 'scripts/ant.xml' as the script is not trusted
    at org.hl7.fhir.igtools.templates.Template.runScriptTarget(Template.java:162)
    at org.hl7.fhir.igtools.templates.Template.onLoadEvent(Template.java:322)
    at org.hl7.fhir.igtools.publisher.Publisher.initializeFromIg(Publisher.java:1276)
    at org.hl7.fhir.igtools.publisher.Publisher.initialize(Publisher.java:1204)
    at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:659)
    at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:6937)

Jose Costa Teixeira (Feb 03 2020 at 18:54):

Let me see if I can check what's up

Jose Costa Teixeira (Feb 03 2020 at 19:23):

@Chris Moesel 's analysis is right,
it is looking for hl7.base.template at http://fhir.org/templates/fhir.base.template/0.0.1/package.tgz, instead of the expected hl7.base.template
I don't know how to fix that, the references in the templates seem ok

Grahame Grieve (Feb 03 2020 at 20:02):

sigh. this is my fault - a typo in the package-list.json. And I also failed to clear out my package cache before testing

Grahame Grieve (Feb 03 2020 at 20:03):

@Lloyd McKenzie you were going to update the current templates to all refer to current?

Grahame Grieve (Feb 03 2020 at 20:06):

ok it's fixed now

Jose Costa Teixeira (Feb 03 2020 at 20:21):

confirm, fixed. Thanks

Chris Moesel (Feb 03 2020 at 21:56):

Thanks, @Grahame Grieve and @Jose Costa Teixeira!

Sean McIlvenna (Feb 03 2020 at 23:52):

@Grahame Grieve and @Lloyd McKenzie
To use a specific version of a template, I would put this in the ig.ini file, right

template = hl7.fhir.template#0.0.5
template = hl7.fhir.template#current

Sean McIlvenna (Feb 03 2020 at 23:53):

and is template = hl7.fhir.template the same as template = hl7.fhir.template#current

Grahame Grieve (Feb 04 2020 at 00:01):

yes and yes

Sean McIlvenna (Feb 04 2020 at 00:02):

thx

Sean McIlvenna (Feb 04 2020 at 00:03):

@Rick Geimer I'll add "template" as an extension to IG that the user can specify. If no value is specified, it will default to "hl7.fhir.template#current", otherwise it will use what the user enters, and provide suggestions for known templates based on the package-list.json that @Grahame Grieve mentioned.

Sean McIlvenna (Feb 04 2020 at 00:03):

@Grahame Grieve , any hopes for a single json file that represents all known templates and their versions in the future?

Sean McIlvenna (Feb 04 2020 at 00:03):

i.e. hl7.cda.template

Jose Costa Teixeira (Feb 04 2020 at 00:11):

If no value is specified, I would default to the base template

Grahame Grieve (Feb 04 2020 at 00:13):

any hopes for a single json file that represents all known templates and their versions in the future?

I woudn't consider that but I would consider adding a templates.json to http://fhir.org/templates

Sean McIlvenna (Feb 04 2020 at 02:56):

ok. thanks @Grahame Grieve now that I know of http://fhir.org/templates, though... I'm wondering if you could add hl7.cda.template to it? I assume that with these changes, I will no longer be able to publish cda-core-2.0 or cda-ccda-2.2 using the new template system until hl7.cda.template gets added to this list of published templates

Grahame Grieve (Feb 04 2020 at 02:56):

I have to add a few more templates to the system. Who maintains hl7.cda.template?

Sean McIlvenna (Feb 04 2020 at 02:57):

I suppose I do

Sean McIlvenna (Feb 04 2020 at 02:57):

:)

Grahame Grieve (Feb 04 2020 at 03:28):

ok, so, here's how it works:

• the stated version, and the version of it's dependencies has to be "current"
• there'll be a package-list.json; you set up new releases by editing that.
• once you're ready to go, let me know, and I'll update the versions to all correct and release a new version

Grahame Grieve (Feb 04 2020 at 06:03):

ok inducted and published as v 0.0.4

Catherine Hosage Norman (Feb 04 2020 at 08:26):

I am getting a new error
Error : Fatal error during transformation using C:\PQCMC_IG\template\scripts\onGenerate.genJson.xslt: Processing terminated by xsl:message at line 7 in onGenerate.genJson.xslt; SystemID: file:/C:/PQCMC_IG/template/scripts/onGenerate.genJson.xslt; Line#: 7; Column#: -1

Line #7 is <xsl:message terminate="yes">IG must include a definition parameter with a code of 'releaselabel'. Value can be 'CI build' or some other status.</xsl:message>

Is this looking for a parameter in the control file? I already have "status" : "ci-build" in package-list.json.

Catherine Hosage Norman (Feb 04 2020 at 08:52):

I added the following to the control xml file. Seems redundant to the ig.ini info. I am past these errors.
<parameter>
<code value="releaselabel"/>
<value value="CI Build"/>
</parameter>
<parameter>
<code value="copyrightyear"/>
<value value="2020+"/>
</parameter>

Now on to the next error. Have you stopped supporting spreadsheets? Files that worked last week do not work anymore. I have a sample xml profile that works fine, but when I use the '-spreadsheet' suffix it cannot find the file. If I take off the suffix, it finds the file but cannot parse it.

Jose Costa Teixeira (Feb 04 2020 at 08:54):

The parameter needs to be in the IG xml itself

Catherine Hosage Norman (Feb 04 2020 at 08:55):

Thank Jose, do you know if there is a new parameter for spreadsheets? It just stopped working since last week.

Grahame Grieve (Feb 04 2020 at 08:58):

I don't think there's been any change there

Lloyd McKenzie (Feb 04 2020 at 09:17):

The parameter goes into your ImplementationGuide, not structure definitions. I'll fix your IG

Lloyd McKenzie (Feb 04 2020 at 09:27):

Though it looks like you need to commit first because the version in Git isn't using ig.ini yet. (@Catherine Hosage Norman )

Catherine Hosage Norman (Feb 04 2020 at 09:30):

I cannot get it to build locally so I have not put it in git. Is there a parameter for using the spreadsheets? Both of these worked last week, now they cannot be found.

Catherine Hosage Norman (Feb 04 2020 at 09:57):

I have tried all sorts of options. I put back in
<extension url="http://hl7.org/fhir/StructureDefinition/implementationguide-spreadsheet-profile">
<valueBoolean value="true"/>
</extension>
after I had taken it out a couple of weeks ago because it was throwing an error on saving. Now the save is ok, but still getting unable to find if I save the Excel file as pharmqualityspecification-spreadsheet.xml and get "unable to parse" if I save it as pharmqualityspecification.xml I am successful with small profile defined as xml method and no spreadsheet. I really did not want to convert to xml definition at this point, but it there is no other option in the short term let me know.

Lloyd McKenzie (Feb 04 2020 at 12:36):

Spreadsheets should work fine. Commit the current state and I'll work on making it build tomorrow night Sydney time.

Last updated: Apr 12 2022 at 19:14 UTC