Adding template for detailed use case documentation and first use case in-detail document

[AramZS]

This PR proposes a way to state use cases in more detail than the summary table currently allows for while retaining the readability of the summary table by breaking detailed explanations off into their own folder.

This also proposes that each use case adhere to a markdown-style page metadata structure that is fully worked out in the extended template. This metadata structure would allow the markdown files to be parsed by a build or scanning tool that could then use them to create filters or sorting methods as requested in previous conversations in the group.

I do not yet propose the methodology for how to handle that build process, I think the first step is to assure this addresses all needs both in form, format and level of metadata included. Assume that each metadata field would be able to act as a filter or sort, depending on data-type. If this seems sufficient we can start building out further documents and approach a build or Github action hook process that can turn these into a single sort-able, expandable page or some other format.

Long term the product created out of these separate documents could, like the Dashboard, represent a product of this group and replace the single support_for_advertising_use_cases document.

In order to help make this process clearer, I have added the first in-detail document for Viewability / IVT as an example.

[AramZS]

From meeting:

Possible other metadata standards:

• http://mirrors.ibiblio.org/CTAN/macros/generic/markdown/markdown.pdf
  • & - https://github.com/Witiko/markdown
• https://fletcher.github.io/MultiMarkdown-5/syntax.html

Possible other template structures:

• Bikeshed
  • https://w3c-ccg.github.io/bikeshed_instructions.html
  • https://tabatkins.github.io/bikeshed/
• ReSync
  • https://github.com/w3c/respec

[AramZS]

This is not intended to exclude any possible metadata standards, but I will note on here that if we go towards Jekyll as our build tool (which is easy to do, because it is built into GitHub Pages) this is a metadata standard that Jekyll understands. This is simply my go-to format for that reason and because I've done a some work specifically using it with Jekyll.

If we move towards a different build tool, then it may make sense to move towards a different metadata standard. I'll look into the w3c standards and I'll also note that using a not-built-into-Github build tool to publish these sort of pages would open up significant possiblities in formatting and metadata style

[wseltzer]

@dontcallmedom your input on tooling welcome

[dontcallmedom]

I believe jekyll collections would probably work quite well to deal with that kind of content, combined with JS to help sorting / filtering.

it would be easier to assess with a clearing understanding of what would be expected from the dashboard, maybe through a handcrafted HTML mockup

[AramZS]

There seems to be an interest in the group so I think an HTML mockup makes sense. I'll work on that first. I agree that collections looks like a good way to go.