Added formulation support and test cases

[stevespringett]

Implements and closes #31

[jkowalleck]

review done.
Things that made me reject the PR are marked with a red cross ❌

---

general remark to the XML: most of those simple types - like string, bool and dateTime - could be attributes, instead of child elements.
examples:

• https://github.com/CycloneDX/specification/pull/222/files#r1200081423
• https://github.com/CycloneDX/specification/pull/222/files#r1200087127

general remark on JSON: why not have key-value-pairs as open object?
examples:

• https://github.com/CycloneDX/specification/pull/222/files#r1200153093

general remark: I do not like elements which have all child-nodes/properties as optional, no required content at all.
what purpose do they have, then? Let's reconsider which child-node(s)/propertie(s) are actually defining the element, and make this one(s) mandatory.
examples:

• https://github.com/CycloneDX/specification/pull/222/files#r1200118438

[jkowalleck]

@stevespringett

• Could we have extra values for taskType called patch?
  So I could have a resourceReferenceChoice that points to a patch file that is applied?
  i see an already existing value merge -- isn't a merge just the process of applying a patch?
• I understand taskType copy can be used for local or remote resources.
  A copy of a remote resource https://acme.org/myFile means a download, right?
• i see an existing taskType clone. Is this related to VCS?
  if so: this wording is too specific to git, in SVN it's called checkout.
  I'd suggest removing clone and use the existing copy for it.
• is there a task for publish/upload? there is a deliver, which i do not understan properly.

my questions are basically caused by the fact that there are no descriptions for the enums.
i'd love to have them added.

---

💡 if some of the enum values are scoped to VCS, then they should have common prefix, like vcs:clone, vcs:commit, vcs:merge, vcs:push. And the names should be generalized, not git-specic.

---

PS: i see that pedigree already has patches/diff as an element. maybe reuse it? or link to it?

PPS: see #245

[stevespringett]

@mrutkows I need your help in answering some of these concerns. Time is running out as this issue is up for vote.

[mr-zepol]

I see that the definition of this object (Task) has a lot of duplication info in Formula, wouldn't it be better to create an object to encapsulate that?

[stevespringett]

Yes it would be. There's a lot of duplication, in part because we're still using draft-7 and the documentation tool we use doesn't work correctly when creating reusable properties and including them with anyOf or allOf. We tried multiple times, but documentation took priority over schema optimization. Once we migrate away from draft-7 and update the documentation tool, we should be able to optimize the schema.

[mrutkows]

@mr-zepol I did create a reusable type, but was told it was too hard for XSD to represent/consume

[mr-zepol]

My suggestion was basically because trying to model this in Java for example would mean a lot of duplicate code as well

[stevespringett]

@mr-zepol There's no reason why the Java implementation needs to implement duplication. You can (and likely should) have some abstract classes where all the commonality is located and can be extended by concrete classes.

[jkowalleck]

@mrutkows emphasized to revisit the inputs and outputs.
❗ they should be key value pairs, instead of strings.

• input and output should be Key-Value-pairs instead. key should be string, value should be either string, number, int, float, boolean...any scalar type.
• @stevespringett mentioned we should use the existing "parameter", that should be used for input/output.

---

PS:
it was agreed to keep it as string for 1.5, and expand in a later version, if needed;
see #246

[stevespringett]

New tickets created referencing this PR which identify potential improvement areas in v1.6