0.1.0

Key changes:

• Corrected the QA template that wasn't properly checking for both names and descriptions
• Improved rendering of valuesets

Authoring impacts:

• Artifacts that were previously only raising one error (missing name) may now raise an additional message (due to a missing description)

0.0.2

Key changes:

• Changed handling of pages so we didn't copy the markdown and XML into the output
• moved to using IG instead of ini file for parameters
• put extension documentation in more logical order
• get all relevant schemas, not just r5 (and changed where they're stored)
• refactored ant to allow derived templates to override
• improved rendering of artifact list
• fixed issues with table of contents not appearing
• fixed typos in grouping descriptions
• allow looking up resources even if some resources are already listed

Authoring impacts:

• If you were previously putting content in the pages or pagecontent folders assuming it would be copied directly to the output folder, this will no longer work. To achieve this behavior, you'll need to put the content in the input/images folder instead. (Though if you're defining custom css files or similar structures, you might look at defining a local template or even a shared template instead.)
• Most, though not all of the parameters in the ig.ini file are now migrated to the ImplementationGuide (where they should have been in the first place). Authors will need to remove these entries from their ig.ini and make the necessary changes in their input/[igcode].xml or input/[igcode].json file. Specific changes are as follows:
  • the version parameter will migrate to the version element in the ig file (which should appear immediately after the url element. e.g. <version value="0.0.1"/> or "version":"0.0.1",`
  • the license parameter will migrate to the license element in the ig file (which should appear immediately after the packageId element). e.g. <license value="CC0-1.0"/> or "license":"CC0-1.0",
  • the fhirspec is dropped entirely. It can be inferred from the fhirVersion parameter that already appears within the IG.
  • the remaining parameters all appear as ImplementationGuide.definition.parameter elements which appear after the page elements. Of these, usage-stats-opt-out, copyrightyear, excludexml, excludejson, excludettl, excludemaps all map directly. I.e. if the ig.ini file had copyrightyear = 2019+, the ig file would have <parameter><code value="copyrightyear"/><value value="2019+"/></parameter> or "parameter"=[...{"code"="copyrightyear","value="2019+"},...]. However, one parameter has changed. The value that was called ballotstatus in the ini file is called releaselabel when expressed as a parameter. (NOTE - Check that all of the above-listed parameters are expressed completely in lower-case.)
• If you had schema references in any of your source files, the location of those schemas has now changed. Revise your schema references to be a relative path to input-cache/schemas/r[x] where 'x' is the release number 2, 2b, 3, 4 or 5. As well, if you had committed input-cache/schemas-r5, you should use git delete to remove that folder and instead git-add the new schemas folder.
• Ensure that all of your artifacts have both 'name' elements and 'description' elements. For infrastructure resources like StructureDefinitions, if this is not done by specifying a title and definition in the implementation guide, these values will be retrieved from the artifact's metadata. In spreadsheets, the 'shortname' and description of the 'root' element for the profile will be used. However, for examples, the only way to set these values is to list the artifact in the implementation guide and provide a name and description there.
• The default behavior of the template is to look for candidate artifacts if no artifacts specified in the IG and to use only the listed artifacts if any are specified in the IG. However, because it's now necessary to enumerate examples in the IG (to provide names and descriptions), but authors might not want to enumerate all of their artifacts, a new parameter can be specified in the ImplementationGuide.definition.parameter list - find-other-resources. If this parameter is set to 'true', the template will look for additional artifacts, even if some artifacts are already listed in the IG. Authors who want this behavior should add this parameter with the appropriate value.