extending parts or making a meta object available within tex template

[stevejpurves]

Currently a parts object/map is exposed in the jtex template. The entries in this map contain the concatenated content from parts found in the document, keyed by the part name.

In this concatenation we've lost some information though -- we don't know how many parts with the given name were included in the document. For the use of part to identify small sections of content like abstract or acknowledgments this is perhaps fine.

However, parts are also used to handle appendices, which are likely to contain longer form content complete with document structure in terms of headings. There having access to only concatenated content is limiting.

For example, the issue opened by @dressedfez here: myst-templates/physical_review_journals#9

How could we deal with this? some ideas are:

1. change the parts object structure now, from Record<string, string> to something like Record<string, { content: string, count: number }> this would involve updating all templates and would be a breaking change but maybe it's still better to do this now and have the parts representation become more flexible -- for example individual content chucks for each part could be made accessible here in additional to the concatenated content, and the object based format means it's easy to add additional properties in future, like actual work and character counts for automated checks...
2. add a meta object from which you'd be able to determine the number of parts, and other "meta" information about the parts, and the document in general -- e.g. number of citations, heading structure, etc... -- this seems interesting but other than the parts I am not sure of the use case for this.
3. Use a specialised string, with patched prototype allowing us to add a custom field (doesn't feel great)

Perhaps we've underestimated the degree of detail we need on the parts so far and we should address this by doing 1 now?

cc @rowanc1 @fwkoch

[dressedfez]

To add my grain of salt here. I would as well go for option 1 since:

a) the number of templates seems to be still relatively small and a breaking change would not cause a big wave of work and

b) the more information one can automatically determine from the structured text the better. As an example, one could automatically
determine the number of characters or words used in an appendix to inform the writer that he or she has reached the limit of words or
characters set by the journal.

[stevejpurves]

As there are definitely more ways that parts can be used if we have access to the fragments in place of the concatenated content, how about a non breaking change of adding rawparts: Record<string, string[]> as an additional object alongside parts which is accessible to the template?

cc @fwkoch @rowanc1