docs: fixes rendering of parameter table in docs for app desc and deployment

[singhmj-1]

Description

The docs rendered for application-description and application-deployment show name object to be an explicit field in parameters object (a key:value map), whereas it refers to the key attribute of the map.

Issues Addressed

Closes #169

Change Type

Please select the relevant options:

• Fix (change that resolves an issue)
• New enhancement (change that adds specification content)
• Content edits (change that edits existing content)

Checklist

• I have read the CONTRIBUTING document.
• My changes adhere to the established patterns, and best practices.

[singhmj-1]

Fixes for application description:

Fixes for application deployment:

[Silvanoc]

This PR makes a moving target for the Data Model PR #158. The hereby introduced changes should be also made in the branch of PR #158.

[chrisgclayton]

Looking at the images vs. the actual files, which I assume are snapshots of the actual files I noticed there is a "typo" I assume in Image 1. You will notice it says in the description of parameters:
e.g., e.g., (doubled up).

I get that this passed the SUP stage I assume so it is more of a question than asking for a change.

Moving something from a formal field (i.e., metadata.name) to a property bag key/value typically implies there are not special rules of processing associated with it etc. I would assume that a formal name would have some guardrails? Also is there not special meaning to it? It feels like movement from formal to property bag is generalizing something that should not be? (again please take this as a question as I was not involved at the time of the SUP)

[singhmj-1]

I'm not fully aware of how this data structure originally got introduced into the spec, but a two quick thoughts on the layout:

1. Since the schema is built on LinkML, we can technically write rules for map keys, but I'm doubtful that downstream code-generators or language-specific libraries can enforce those strictly by default. So, I agree this could be an issue for application-deployment objects.
2. That said, keeping a map structure within the application-description object, which is original source config template, makes some sense as it provides a direct, clean lookup mechanism for validating if the application-deployment is correct or not. But keeping guardrails, wherever possible, is good practice, so your observation weighs more in this case as well.

And thanks for reporting that double word issue, I'll fix that one.

[ajcraig]

Hey @singhmj-1
PR looks good but a couple items I saw when rendering.

I think you need to inject a single line after line 71. See line below in markdown and rendering screenshot. Reason I mention that is, when I render it, the helm exceptions header is getting placed in the table.

---

Also, think it might be good to reiterate the description you placed in the top-level attribute down in the parameter attributes section. Readers might have forgot what that description was by the time they get to the relevant section.

[singhmj-1]

@ajcraig issues addressed.

[ajcraig]

Looks good, following link fixes via Phil.