528 standalone sdpi editorial content update#542
Conversation
Updated sdpi-supplement files to include a single file (all were previously commented out), to help reestablish a baseline branch.
Incorrect directory for include file.
"<<...>>" was not commented out.
After updating branch from master (locally) updated the changelog.
|
@JavierEspina & @d-gregorczyk -- Today I started working on this ... for real! Looking at the use of "supplement" in the files (e.g., with [#supplement_ ...], it looks like the usage is limited to only six files. So hopefully when I do the separation tomorrow, it is limited to just that and I can do the updates without mucking with too many files. Hopefully ... I did pull in the latest Master to this branch. So at least we are starting at the same baseline. |
|
2026.07.10 SDPi Friday - @JavierEspina @d-gregorczyk FWIW - Post history service and other updates to Master, this branch was successfully rebased to Master with only one change in the gitignore file. |
… Lists Initial triage of replacing references to "supplement" in all the sdpi-standard related files. This was a gross, brute force change, before going through the editorial content pass.
|
2026.07.15 Update Notes:
|
First pass at moving structural content from the standard to the supplement/ space.
|
2026.07.16 Update Notes:
<will see if it worked ... Friday!> |
Updated sdpi-supplement include files to fix undefined labels in the supplement ... fingers crossed
Numerous typo corrections (e.g., "ol1" => "vol1" TEST: Bringing in TF-0 content, do the files all need to be renamed and labels renamed IF it is only in the sdpi-supplement.adoc "tree" ???
Running a test on a single definition "term_conformity_assessment" to see if it can be scoped to the supplement folders and includes ... or not.
|
2026.07.20 Update Notes: Resolved to resolve build issues from Thursday 16 July (see above) - VERY VERY FRUSTRATED!!! @d-gregorczyk @PaulMartinsen -- In unraveling this onion of reference hell, I did an experiment that I think might have worked (it seems to have worked in my Fix #3 run. QUESTION: When we ended up building the sdpi-standard & sdpi-supplement outputs, IF I move all but the top-level sdpi-supplement.adoc files under the supplement/ folder AND if I simply copy a file like TF-0 Appendix D with definitions into that supplement/ folder tree - so that for the supplement, only stuff loaded from that top level document are processed ... none of the sdpi-standard tree files are included - is there any duplication of build content across the two document trees? IOW - if the same label (e.g., "term_conformity_assessment") is defined w/o supplement_term_conformity_assessment change, will there be any duplication errors or other issues when processing the source and rendering the supplement document? My initial experiment indicates that the answer is "you're OK doing that, Todd" and if so ... I've wasted a chunk of time BUT moving forward will be much faster! |
|
@d-gregorczyk @PaulMartinsen ... My "local" build, by running: .ci/asciidoc-converter/build_document.bat Resulted in an error: e: file:///C:/Docs/macStuff/Trusted%20Solutions/SDC/SDPi-FHIR/Repositories/DEV.SDPi/.ci/asciidoc-converter/src/test/kotlin/org/sdpi/ConvertUseCasesTest.kt:55:28 Unresolved reference 'useCaseReferences'. But since I wasn't doing it from a "green" set of code ... I assume that it will work better once I get my other push to build correctly. Right? |
2 participants
📑 Description
This PR provides an initial content separation between the SDPi Standard (standalone) and Supplement (to be integrated into the IHE DEV TF at some point). Though the changes are all editorial in nature, given the extensive label changes, they touch nearly every file in the project!
☑ Mandatory Tasks
The following aspects have been respected by the pull request assignee and at least one reviewer: