Additional values added to the stored config information

[iherman]

Issue #478 has recently been closed, adding a copy of the author's config information in the output in JSON syntax, encapsulated in a <script> element. This is, I believe, great, it makes the job of creating various post-processing tasks (as the recently added EPUB generation service) easier.

However, it may be worth considering adding some more information to that stored JSON. The most important features I missed, when completing my particular post-processor are:

• Various config variables can be added as query parameter to the documents URI. Eg, it is possible to call out something.html?specStatus=WD. When saving the file into HTML one does get a Working Draft (regardless of what the embedded config says in the original source) but the generated JSON is not set to, in this case, WD. In practice, this means that a post-processor has to parse the URL and extend the JSON based information.
• The dated URI is important for many purposes; e.g., it is the reliable unique identifier for the final document. Generating the dated URI is of course doable, based on the document's status, short name, and the publication date. However, it is not entirely obvious, because there is no one-to-one correspondance between the status and the URI pattern: indeed, there may be different status terms mapping to the same pattern and this has to be manually added to the code (e.g., both FPWD and WD map to WD).
• The correct "subtitle" (e.g., "W3C Last Call Working Draft") that may have to be used when creating a separate index page, cover page for an EPUB file, etc. At the moment, a mapping table from the status to the corresponding text should be added

There are also some even more minor ones like the publication date in a specific format (the initial config may not contain a date). All these point at the same issue: that a post-processor must replicate some of the logic which is present somewhere in the ReSpec code and whose result is lost once the processing is over. (Alternatively, the post-processor has to scrape the generated HTML code, which is even worse.) Again, to emphasize, none of these are major, but it may be worth considering three alternatives nevertheless:

1. Leave it at the current version, ie, let the post-processor do the extra processing when needed.
2. Analyze the needs and add some more extra information to the JSON config information accordingly (I believe the first item above is the most obvious additional information that is worth considering).
3. Store the generated, internal config of ReSpec instead of the user's one. That has the advantage of storing all kinds of extra information that may become handy (e.g., it seems to store the term references, i.e., it would be easier to extract and create some sort of a glossary) but it has the disadvantage of storing a significant amount of data that most users would not care about.

I am not sure myself which is the best option to follow. But it may be worth discussing.

[marcoscaceres]

Not sure if this is still useful to you, @iherman, but I'm adding:

• publishISODate
• generatedSubtitle
• query params as you mentioned above.

[iherman]

@marcoscaceres thanks. I will not change my post processor now, following the "Ain't broken, don't fix it" principle, but it is good to have this nevertheless!