Info for commissioned content

[bquinn]

This came up in the DPP LPX discussion, but it might be useful for pre-created content as well as live.

Properties:

• Purchase order number
• Work order number
• Ordered by (person's name)
• Ordered date

These are used by Arqiva live broadcast objects,

Johan has also shared:

"commissionedby": {
            "title": "Commissioned by",
            "description": "$$TT: When pubstatus is 'commissioned', this field tells who commissioned it.",
            "type": "array",
            "items": {"type": "string"}
        },

[bquinn]

@jolla56 pointed out that this was raised long ago as issue #26 !

[bquinn]

Suggested structure:

"commissioning": {
  "commissionedby": [ "Julie Bloggs", "Fred Smith" ],
  "commissioneddate": "2024-02-05",
  "purchaseordernumber": "PO16382",
  "workordernumber": "17364382189"
}

Note that "commissionedby" is an array of strings as per Johan's original suggestion.

[bquinn]

Discussion: should we have an array of contactinfoType objects instead of an array of strings?

[bquinn]

Discussion: should we have an array of key-value pairs which can be used for things like order number, rather than baking them into the spec? Similar to altId.

commissioningReferences ? (or just references as it's already inside a commissioning block)

[bquinn]

So after discussion, the example would look like:

"commissioned": {
  "by": "Julie Bloggs",
  "on": "2024-02-05T12:34:56Z",
  "references": {
     "purchaseordernumber": "PO16382",
     "workordernumber": "17364382189"
  }
}

Thoughts:

• Should commissioning info be a repeatable block? Can things be commissioned by more than one separate entities?

Decision:

• For now, go with the above. Test our assumptions at the hackathon.

Separately, an old example from Johan:

"pubstatus": "commissioned",

"commissionedby": [
"16110"
],
"headline": "Emma Henningsson",
"commissioncode": "8888",

[bquinn]

@bquinn to add this to draft schema on #160

[pmougin]

Discussion: should we have an array of key-value pairs which can be used for things like order number, rather than baking them into the spec? Similar to altId.

As JSON natively provides a key-value pair functionality, I think it would be redundant to add one. If some property is not baked in the ninjs spec, one can already add it using JSON directly (e.g. { ..., "orderNumber" : "1234", ... })

[bquinn]

Philippe wrote:

As JSON natively provides a key-value pair functionality, I think it would be redundant to add one. If some property is not baked in the ninjs spec, one can already add it using JSON directly (e.g. { ..., "orderNumber" : "1234", ... })

This is a good point, and it's actually what I did in the example without thinking about it. So instead of having "name": "xxx", "value": "xxx" (which is what we do with altId), we could just leave the schema for the reference part open and people can add their own key/value pairs as they wish. But does that make it harder for people to validate, or to write code around the data?

[bquinn]

Thinking about making it more consistent with the rest of ninjs 2.x...

"commissioned": {
  "by": "Julie Bloggs",
  "on": "2024-02-05T12:34:56Z",
  "references": [
     { "name": "purchaseordernumber",
        "value": "PO16382"},
    {"name":      "workordernumber",
       "value":  "17364382189" }
  ]
}

This would keep the ninjs 2.x property of the schema being able to be converted to Protobufs, Avro etc.

[iyoung]

Closing this off as a structure to support this requirement is now part of the 2.2 draft schema.