Stream: IG creation
Topic: Validation failure when value[x] is integer or code
Saul Kravitz (Mar 02 2022 at 23:33):
I'm having validation issues during publication when a field is defined as either integer or code (also date/code). The error message says that the value only allows for one type, when it is clearly defined for two.
Observation.value.ofType(dateTime).extension[0].extension[3] (l58/c12) error The Extension 'http://hl7.org/fhir/us/vrdr/StructureDefinition/Date-Time' definition allows for the types [code] but found type time
Observation.value.ofType(dateTime).extension[0].extension[3].value.ofType(time) (l61/c12) error This element does not match any known slice defined in the profile http://hl7.org/fhir/us/vrdr/StructureDefinition/Date-Time and slicing is CLOSED: Observation.value.ofType(dateTime).extension[0].extension[3].value.ofType(time): Does not match slice 'valueCode'
The value of the extension is:
{
"url" : "http://hl7.org/fhir/us/vrdr/StructureDefinition/Date-Time",
"valueTime" : "12:01:02"
}
@Chris Moesel
The definition is: http://build.fhir.org/ig/HL7/vrdr/branches/validationbug/StructureDefinition-Date-Time.html
Or, here is the FSH and JSON:
https://fshschool.org/FSHOnline/#/share/36TljQ1
Lloyd McKenzie (Mar 03 2022 at 03:12):
Extension is defined incorrectly. There should be no 'valueCode' element. If you want to constrain the code slice, it MUST be value[x] with an appropriate id and slice name.
Chris Moesel (Mar 03 2022 at 15:53):
@Lloyd McKenzie - SUSHI still outputs all extensions like this and they generally don't cause problems. IG Publisher handles them well since this was an approach that was previously supported (and maybe even encouraged?). SUSHI will switch to useing value[x] and slicenames in SUSHI 3.0 (since it is a major change).
That said, when Saul initially asked me about this privately, I thought it might be related to id/path as well. So I manually modified it to use the Extension.value[x]:valueCode id and Extension.value[x] path instead -- but still got the same exact error. So I don't think that is it.
Lloyd McKenzie (Mar 03 2022 at 18:40):
@Grahame Grieve
Saul Kravitz (Mar 10 2022 at 23:44):
@Grahame Grieve
Is this:
a) acknowledged as an IGP defect? (from @Chris Moesel exploration, it seems like it may be)
b) if yes to a, likely to be fixed?
Just trying to decide whether I can have real examples, or just examples in the narrative.
thx
Grahame Grieve (Mar 10 2022 at 23:49):
it's still on my todo list
Grahame Grieve (Mar 15 2022 at 11:26):
@Lloyd McKenzie I get this trying to run that branch referred to above:
Grahame Grieve (Mar 15 2022 at 11:26):
onGenerate.jira.generate:
[xslt] Processing /Users/grahamegrieve/temp/igs/vrdr/template/package-list.tmp.xml to /Users/grahamegrieve/temp/igs/vrdr/template/package-list.xml
[xslt] Loading stylesheet /Users/grahamegrieve/temp/igs/vrdr/template/scripts/onGenerate.package-list.xslt
[xslt] Processing /Users/grahamegrieve/temp/igs/vrdr/template/jira.tmp.xml to /Users/grahamegrieve/temp/igs/vrdr/template/jira.xml
[xslt] Loading stylesheet /Users/grahamegrieve/temp/igs/vrdr/template/scripts/onGenerate.jira.xslt
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Date Day
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Date Month
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Date Year
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Partial Date
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Filing Format
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Manner of Death
**WARNING** Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Place of Injury
Found multiple candidates for artifact ValueSet-vrdr-manner-of-death in previous jira-spec-info<artifact xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="StructureDefinition/vrdr-manner-of-death" key="StructureDefinition-VRDR-Manner-of-Death" name="Manner of Death"/><artifact xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="ValueSet/vrdr-manner-of-death" key="ValueSet-vrdr-Manner-of-Death" name="Manner of Death VS"/>
[xslt] /Users/grahamegrieve/temp/igs/vrdr/template/scripts/onGenerate.jira.xslt:111:7: Fatal Error! Processing terminated by xsl:message at line 111 in onGenerate.jira.xslt
[xslt] Failed to process /Users/grahamegrieve/temp/igs/vrdr/template/jira.tmp.xml
Publishing Content Failed: Fatal error during transformation using /Users/grahamegrieve/temp/igs/vrdr/template/scripts/onGenerate.jira.xslt: Processing terminated by xsl:message at line 111 in onGenerate.jira.xslt; SystemID: file:/Users/grahamegrieve/temp/igs/vrdr/template/scripts/onGenerate.jira.xslt; Line#: 111; Column#: 7 (02:40.0486)
(02:40.0488)
This error was created by the template (02:40.0488)
Grahame Grieve (Mar 15 2022 at 11:26):
this looks like an error in the template to me
Lloyd McKenzie (Mar 15 2022 at 13:05):
That seems to be a pretty clear error message. Do we know that the names are unique and that there aren't duplicates in the committed jira-spec file?
Grahame Grieve (Mar 15 2022 at 19:55):
don't know, but the build shouldn't fail completely for that reason
Grahame Grieve (Apr 01 2022 at 00:53):
anyway @Saul Kravitz I'll look at this when it builds
Lloyd McKenzie (Apr 01 2022 at 01:47):
You don't have control over it failing there Grahame. The transform deliberately chokes with a fatal error.
Grahame Grieve (Apr 01 2022 at 02:40):
I don't think it should. It should be error in qa.html
Lloyd McKenzie (Apr 01 2022 at 04:01):
There's no ability there to spit out a QA error.
Grahame Grieve (Apr 01 2022 at 04:16):
we could create one.
Lloyd McKenzie (Apr 01 2022 at 13:43):
It's an XSLT that's spits out something else. With XSLT 1.0, a given transform can only spit out one thing. We could set up the transform to run in two different modes, one that spits out errors and one that spits out the desired file, then call it twice. I'm not sure why we'd bother adding that complexity when the problem identified is one that has to be fixed.
Grahame Grieve (Apr 01 2022 at 20:13):
what does it spit out?
Lloyd McKenzie (Apr 01 2022 at 22:14):
The target Jira spec file
Grahame Grieve (Apr 01 2022 at 22:15):
I could look at that file and pick up errors if it's an OperationOutcome?
Lloyd McKenzie (Apr 02 2022 at 02:16):
I guess the normalization process we use for comparison could strip out OperationOutcomes
Last updated: Apr 12 2022 at 19:14 UTC
