Stream: IG creation
Topic: Problem updating xml in JIRA-spec-artifacts-
Mark Kramer (Nov 03 2021 at 16:16):
I'm trying to check in FHIR-us-mcode.xml and getting validation errors. Here are type of statement causing the problem:
<artifact deprecated="true" id="StructureDefinition/mcode-cancer-patient" key="cancer-patient" name="Cancer Patient Profile"/>
<artifact id="StructureDefinition/mcode-cancer-patient" key="StructureDefinition-mcode-cancer-patient" name="Cancer Patient Profile"/>
I am getting two types of error messages:
[schemavalidate] /home/runner/work/JIRA-Spec-Artifacts/JIRA-Spec-Artifacts/xml/FHIR-us-mcode.xml:33:135: cvc-identity-constraint.4.1: Duplicate unique value [StructureDefinition/mcode-cancer-patient] declared for identity constraint "artifact-id-unique" of element "specification".
and:
[xslt] ERROR: Artifact with key FHIR-us-mcode-cancer-patient in specification FHIR-us-mcode has been removed or changed. Keys should never change - just change the name. Keys should also not usually be removed. Instead, set the 'deprecated' flag to true. Keys can only be removed if no JIRA tracker references that artifact. If this is the case and the key should really be removed, please coordinate with an administrator.
Jean Duteau (Nov 03 2021 at 16:29):
you're intentionally trying to change the key of that structure definition?
David Pyke (Nov 03 2021 at 16:31):
Yeah, moving from the old key format to the new causes all kinds of problems @Lloyd McKenzie
Lloyd McKenzie (Nov 03 2021 at 17:04):
You can't change keys. Keys need to stay the same forever or it breaks Jira. (That's not entirely true - there are back-end things we can do, but they're painful and time-consuming, so the default answer is 'once a key exists, it never goes away and never changes')
Lloyd McKenzie (Nov 03 2021 at 17:04):
Keep the key as it was and just change the name and/or artifact id.
Mark Kramer (Nov 03 2021 at 17:12):
Noting that other xml's don't have keys for deprecated items, I deleted the keys. That only gave another error, and it is a frustrating one, because it is claiming something changed, but I am directly copying jira-xml-new.
Mark Kramer (Nov 03 2021 at 17:13):
[xslt] ERROR: Artifact with key FHIR-us-mcode-StructureDefinition-mcode-evidence-type in specification FHIR-us-mcode has been removed or changed. Keys should never change - just change the name. Keys should also not usually be removed. Instead, set the 'deprecated' flag to true. Keys can only be removed if no JIRA tracker references that artifact. If this is the case and the key should really be removed, please coordinate with an administrator.
Mark Kramer (Nov 03 2021 at 17:19):
Impossible. I give up. image.png
Lynn Laakso (Nov 03 2021 at 17:32):
please move this to the #IG creation
Mark Kramer (Nov 03 2021 at 18:04):
https://zulip.com/help/move-content-to-another-stream
This doesn't work for me because "move topic" is not a menu choice I have at my disposal.
Notification Bot (Nov 03 2021 at 18:13):
This topic was moved here from #JIRA/Confluence > Problem updating xml in JIRA-spec-artifacts- by Josh Mandel
Josh Mandel (Nov 03 2021 at 18:13):
(@Mark Kramer moving messages across topics is configured as a moderators-only feature here. For anyone who wants to be a mod, please ping me, I expect we could use more :-))
Mark Kramer (Nov 03 2021 at 18:17):
So, just to reiterate the problem... I thought one just had to take jira-new.xml and check it into the Jira-spec-artifacts/xml. But it doesn't work that way, apparently. Nor can I find -- after MUCH MUCH trial and error -- any edits that successfully address the error messages that come out of the verification checks.
Josh Mandel (Nov 03 2021 at 18:18):
This process sounds incredibly frustrating.
Jean Duteau (Nov 03 2021 at 18:58):
@Mark Kramer just to be pedantic - you've run the IG Publisher on your guide, you get the jira-new.xml that it produces, and when you overwrite your entry in your Jira-Spec-Artifacts fork and run the build on that, you get the errors that you posted about a missing key?
Mark Kramer (Nov 03 2021 at 19:00):
Exactly. But the first set of errors are about duplicate keys (I get a bunch of this type):
Duplicate unique value [StructureDefinition/mcode-cancer-patient] declared for identity constraint
Mark Kramer (Nov 03 2021 at 19:01):
I tried just about everything to get around this, and that's when I started seeing errors of this type:
Artifact with key FHIR-us-mcode-cancer-patient in specification FHIR-us-mcode has been removed or changed.
Lloyd McKenzie (Nov 03 2021 at 19:06):
Can you share the current 'new' file?
Jean Duteau (Nov 03 2021 at 19:08):
i just cloned the repo to see and I see the same problem that Mark saw - the jira-new is being produced with artifacts that have the same id but a different key - one is deprecated and one isn't.
<artifact deprecated="true" id="StructureDefinition/mcode-cancer-patient" key="cancer-patient" name="Cancer Patient"/>
<artifact id="StructureDefinition/mcode-cancer-patient" key="StructureDefinition-mcode-cancer-patient" name="Cancer Patient Profile"/>
Mark Kramer (Nov 03 2021 at 19:27):
And I should point out that mcode-cancer-patient is not deprecated and there has never been a version without that profile. However, we did change the title from "title" : "Cancer Patient" to "title" : "Cancer Patient Profile", because that renders better in some contexts. That should be benign; title is just a display text with no deeper significance.
Lloyd McKenzie (Nov 03 2021 at 19:33):
Right. But the process doesn't understand renames, so it instead puts in an 'add' and a 'deprecate'. What you want to do is move the new name to the 'deprecated' key and remove the deprecated flag and remove the new entry with the 'new' key entirely.
Grahame Grieve (Nov 03 2021 at 20:11):
I wonder whether the process could understand renames - whether it would be easier to remember to make a record somewhere when you rename
Mark Kramer (Nov 03 2021 at 20:13):
This has been my day -- 5 hours. Now the problem seems to be revolving around the change of ids on extensions from id="Extension/foo" to id="StructureDefinition/foo" . No idea how to fix the mess.
[xslt] ERROR: Artifact with key FHIR-us-mcode-StructureDefinition-mcode-evidence-type in specification FHIR-us-mcode has been removed or changed. Keys should never change - just change the name. Keys should also not usually be removed. Instead, set the 'deprecated' flag to true. Keys can only be removed if no JIRA tracker references that artifact. If this is the case and the key should really be removed, please coordinate with an administrator.
Mark Kramer (Nov 03 2021 at 20:17):
(deleted)
Mark Kramer (Nov 03 2021 at 20:20):
<!-- Here is a problem -->
<artifact deprecated="true" id="Extension/mcode-evidence-type-extension" key="evidence-type-extension" name="Evidence Type"/>
<artifact id="StructureDefinition/mcode-evidence-type-extension" key="evidence-type-extension" name="Evidence Type Extension"/>
<!-- End of problem ha ha -->
Lloyd McKenzie (Nov 03 2021 at 22:16):
For that one, just delete the 'deprecated' row and submit with the new artifact id and the original key. (Not sure how you got an id of 'Extension/???' originally...)
Lloyd McKenzie (Nov 03 2021 at 22:22):
We've talked about trying to drive renames from Git, but it'd be pretty complex and wouldn't catch the numerous cases where renames happen that don't manifest in Git. For example, if you have 3 examples in a FSH file, renaming the artifact in the FSH file isn't going to show up in Git.
As mentioned in an earlier thread, there's a proposal to revemp this process which will help with some of the pain, but not all of it.
Mark Kramer (Nov 03 2021 at 23:14):
These aren't name, they are Titles. The profile name did not change.
Lloyd McKenzie (Nov 03 2021 at 23:24):
'name' is irrelevant. It's just for computable artifacts. Jira cares about 'title', which is what shows up as artifact/@name. That's what "real humans" are expected to see when looking at an artifact page or table of contents.
Mark Kramer (Nov 03 2021 at 23:27):
Your suggestion 6:16 pm did not work. It is still giving the "Keys should not change" message.
Mark Kramer (Nov 03 2021 at 23:29):
But I copied what was in master, and it passed, finally. But it makes zero sense because the current name is not "Evidence Type"
<artifact id="StructureDefinition/mcode-evidence-type" key="StructureDefinition-mcode-evidence-type" name="Evidence Type"/>
<artifact deprecated="true" id="Extension/mcode-evidence-type-extension" key="evidence-type-extension" name="Evidence Type Extension"/>
:cross_mark:
Mark Kramer (Nov 03 2021 at 23:30):
Anyway, I am so so so done with this and someone with powers can merge it: https://github.com/HL7/JIRA-Spec-Artifacts/pull/333
Mark Kramer (Nov 03 2021 at 23:32):
Mark Kramer (Nov 03 2021 at 23:33):
I suspect this will not get rid of the build warning either
Mark Kramer (Nov 03 2021 at 23:41):
'name' is irrelevant. It's just for computable artifacts. Jira cares about 'title', which is what shows up as artifact/@name. That's what "real humans" are expected to see when looking at an artifact page or table of contents.
However 'title' is not a proper persistent identifier. It is just free text and if one thinks of a better description, the title may change and it is still the same StructureDefinition. Change the ID, however, they it is not the same.
Grahame Grieve (Nov 04 2021 at 00:01):
hey @Mark Kramer congratulations - you are now a qualified expert, well suited to help others with this onerous task. Congratulations on graduating
Mark Kramer (Nov 04 2021 at 00:06):
I know you are teasing, but I truly have no idea what I am doing. What finally passed validation is dead wrong.
Mark Kramer (Nov 04 2021 at 00:11):
When we come to FMG soon for publication approval, that Jira warning will will still be on the QA page.
Lloyd McKenzie (Nov 04 2021 at 01:42):
@Mark Kramer Sorry for not having time to chase this further. First thing I see is this:
In the build log, when processing the Jira file, it's reporting this:
WARNING Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Staging Type Value Set
WARNING Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Staging Type Value Set
WARNING Jira file generation will not be correct because multiple artifacts have the same name (ignoring content in "()"): Staging Type Value Set
Content in round brackets is used to designate old names for the artifact and are ignored in name comparisons and for matching. So, I'd suggest renaming "Staging Type Value Set (for Distant Metastases Category)" to "Distant Metastases Category Staging Type Value Set" or, if you need them to sort together, "Staging Type Value Set - Distant Metastases Category"
I recognize that this rule isn't well-documented. Grahame is working on catching it earlier in the process. If you have thoughts on where would be a good place to put it that IG authors would see, we can put it there too.
Continuing to probe to see what else is going on for you.
Lloyd McKenzie (Nov 04 2021 at 03:51):
I've made some fixes to the HL7 template around generating new Jira files that handled some edge cases you had in your file @Mark Kramer. The only remaining issue that I see now with the generated 'new' file is that it (correctly) yells about there being a duplicate name between an artifact that was deprecated in the 'current' Jira-Spec-Artifacts and an artifact that is being added as 'new' based on the current set of artifacts in the IG - specifically "Evidence Type Extension". (Looks like you yanked it, then put it back?)
The simplest thing to do is to un-deprecate the old artifact (i.e. use the old key) and associate it with the new artifact id. If you do that and commit the Jira spec file, then all should be well.
I have not merged your current pull request so you can look at the results of the new template process and address this one change.
I'm sorry for the time this has cost you :(
Grahame Grieve (Nov 04 2021 at 07:12):
from the next release of the IG publisher HL7 IGs will get a new kind of error:
Grahame Grieve (Nov 04 2021 at 07:12):
Grahame Grieve (Nov 04 2021 at 07:12):
this is because these name clashes are a common source of problems in the jira file
Grahame Grieve (Nov 04 2021 at 07:17):
@Saul Kravitz heads up since that's from yours (I happened to be building that IG when I tested this)
Lloyd McKenzie (Nov 04 2021 at 18:25):
@Saul Kravitz It looks like you manually tweaked your Jira file to avoid the duplicates, but didn't update your source, so presumably you're getting the "not aligned" warning.
Saul Kravitz (Nov 05 2021 at 02:54):
@Lloyd McKenzie my sins in the past with Plan-Net will be atoned for by someone else....I think @Sean Mahoney will have that opportunity.
Mark Kramer (Nov 05 2021 at 21:11):
@Lloyd McKenzie Almost all the errors are now gone, but there is still trouble with Evidence Type Extension. I did exactly what you said (I think), and now I am getting:
[xslt] ERROR: Artifact with key FHIR-us-mcode-StructureDefinition-mcode-evidence-type in specification FHIR-us-mcode has been removed or changed. Keys should never change - just change the name. Keys should also not usually be removed. Instead, set the 'deprecated' flag to true. Keys can only be removed if no JIRA tracker references that artifact. If this is the case and the key should really be removed, please coordinate with an administrator.
Lloyd McKenzie (Nov 05 2021 at 21:18):
It looks like we've now got both old and new committed, each with their own key, so we can't delete one of them anymore. If the issue is you want the new 'current' one to be called "Evidence Type Extension" rather than "Evidence Type" (which is what's there now), then you'll need to change the name of the old deprecated one to something that doesn't conflict. (e.g. "Evidence Type Extension - old")
Mark Kramer (Nov 05 2021 at 22:26):
@Lloyd McKenzie I changed the new name. So now it is good to merge, if you can do so: https://github.com/HL7/JIRA-Spec-Artifacts/pull/336
Thank you for your help.
Rob Reynolds (Nov 05 2021 at 23:21):
<deleted> :grinning:
Richard Townley-O'Neill (Nov 08 2021 at 07:36):
Is it an anti-pattern to have the same title for both a code system and a value set? Or is this just an issue with Jira integration?
Lloyd McKenzie (Nov 14 2021 at 19:40):
In the standard templates, it also means you'll get two entries with the same name in the table of contents - which is less than ideal. So I'd say it's at least somewhat an anti-pattern
Grahame Grieve (Nov 14 2021 at 19:44):
very much so, since newbies are already confused by value set vs code system all the time. So we want to be as clear as we can about this
Last updated: Apr 12 2022 at 19:14 UTC
