SDF doc merge examples and considerations

Given the following two SDF documents for Foo and Bar Objects:

{
  "info": {
    "title": "Foo Object",
    "version": "1.0",
    "license": "BSD"
  },
  "sdfObject": {
    "Foo": {}
  }
}

{
  "info": {
    "title": "Bar Object",
    "version": "1.2",
    "license": "MIT"
  },
  "sdfObject": {
    "Bar": {}
  }
}

Different ways to merging them into one doc:

Top-level array

[
  {
    "info": {
      "title": "Foo Object",
      "version": "1.0",
      "license": "BSD"
    },
    "sdfObject": {
      "Foo": {}
    }
  },
  {
    "info": {
      "title": "Bar Object",
      "version": "1.2",
      "license": "MIT"
    },
    "sdfObject": {
      "Bar": {}
    }
  }
]

Allows sending many dococuments in a single go (payload, doc, etc.).

Doesn't address how to merge any semantics or structure.

Trivial to split.

Combined info-blocks

Info(s) Array

{
  "infos": [
    {
      "title": "Foo Object",
      "version": "1.0",
      "license": "BSD"
    },
    {
      "title": "Bar Object",
      "version": "1.2",
      "license": "MIT"
    },
  ],
  "sdfObject": {
    "Foo": {},
    "Bar": {}
  }
}

Results in a single SDF doc

New quality (infos) or new array semantics for the existing info block needed.

Information lost which definition comes from which document (could add new hint qualities for this?).

Info quality arrays

{
  "info": {
      "titles": ["Foo Object", "Bar Object"],
      "versions": ["1.0", "1.2"],
      "licenses": ["BSD", "MIT"]
  },
  "sdfObject": {
    "Foo": {},
    "Bar": {}
  }
}

Similar outcome and considerations as with the previous method (now for the info block quality names and semantics).

Info quality value arrays

{
  "info": {
      "title": "Foo Object & Bar Object",
      "version": "1.0 & 1.2",
      "license": "BSD & MIT",
  },
  "sdfObject": {
    "Foo": {},
    "Bar": {}
  }
}

Concatenate values from the info block values.

Extra parsing of the information (sometimes) needed. Can easily lead to issues (reserved characters etc.).

More backwards compatible(?) with SDF base.

Info quality in definitions

{
  "info": {
    "title": "Merge of Foo and Bar" 
  },
  "sdfObject": {
    "Foo": {
      "info": {
        "title": "Foo Object",
        "version": "1.0",
        "license": "BSD"
      },
    },
    "Bar": {
      "info": {
        "title": "Bar Object",
        "version": "1.2",
        "license": "MIT"
      },
    }
  }
}

Easy extension to SDF.

Will end up repeating the info block if multiple objects/things defined in a doc that is merged (sdfRef can help here though).

Obj/thing level info block would override document level infos. Doc level info is the default when there is no obj/thing level info.

More complex example

With one more SDF Doc:

{
  "info": {
    "title": "More Objects",
    "version": "1.0",
    "license": "MIT"
  },
  "sdfObject": {
    "More": {},
    "EvenMore": {}
  }
}

merged results with two different ways for re-use

Info block defaults

{
  "info": {
    "title": "More Objects",
    "version": "1.0",
    "license": "MIT"
  },
  "sdfObject": {
    "Foo": {
      "info": {
        "title": "Foo Object",
        "version": "1.0",
        "license": "BSD"
      },
    },
    "Bar": {
      "info": {
        "title": "Bar Object",
        "version": "1.2",
        "license": "MIT"
      },
    },
    "More": {},
    "EvenMore": {}
  }
}

Here More and EvenMore objects simply use the doc-level info whereas Foo and Bar use the info blocks from their org docs.

Using sdfRef

{
  "sdfObject": {
    "Foo": {
      "info": {
        "title": "Foo Object",
        "version": "1.0",
        "license": "BSD"
      },
    },
    "Bar": {
      "info": {
        "title": "Bar Object",
        "version": "1.2",
        "license": "MIT"
      },
    },
    "More": {
      "info": {
        "title": "More Objects",
        "version": "1.0",
        "license": "MIT"
      },
    },
    "EvenMore": {
      "info": {
        "sdfRef": "#/sdfObject/More/info"
      }
    }
  }
}

Considerations

Which of the objectives we value more:

1. Preservation of provenance (and rights!)
2. Compatibility with installed base, which may not get the full function though
3. Avoiding string parsing or other questionable JSON practices

If use definition level infos and sdfRef, should allow info blocks in sdfData and be able to sdfRef those for easy re-use?