terales
commented
5 years ago I love your idea, here is my attempt to create a more precise data model based on your idea (webhooks and all other data types are omitted for now):
Source file for the visualization in Visio 2016 format
Concerns:
Andrew Gibbons @assembledStarDust: how well arrays would scale?
Let's put a 65535 items restriction on the size of array identifiers. In the edge case of utf8 4 bytes chars used in id's for all 1024 characters, it would take up to 270 MB of data transfer or 540 MB if two references would be filled at maximum, but for 99.9% cases, it would be much less.
Also, we would introduce endpoints for quick polling< which would exclude all arrays, as well as special ones which would supply these arrays only with REST-based pagination:
/jobs/{Job.id}/meta (omits all references, only metadata)
/jobs/{Job.id}/inputs (respects REST pagination)
/jobs/{Job.id}/inputs/meta (get's all inputs with internal files only)
/jobs/{Job.id}/tasks/{Task.id}
/jobs/{Job.id}/tasks/{Task.id}/meta (omits all references, only metadata)
/jobs/{Job.id}/tasks/{Task.id}/inputs (respects REST pagination)
/jobs/{Job.id}/tasks/{Task.id}/inputs/meta (get's all inputs with internal files only)
/jobs/{Job.id}/tasks/{Task.id}/deliverables (respects REST pagination)
/jobs/{Job.id}/tasks/{Task.id}/deliverables/meta (get's all inputs with internal files only)
…Jim Compton @jcompton-moravia: what if we have only instructions or links as Tasks input or deliverable? Or even just date as Task deliverable?
what if we have only instructions or links as Tasks input or deliverable?
We can just pass it as a text file and underlying HTTP protocol would handle all encoding, compression and type detection work.
Or even just date as Task deliverable?
Then we can change Task status and set deliveredDate to the date we need.
jcompton-moravia
Alino
assembledStarDust
As per our WG#4 discussion on December 5th, we discussed an alteration to the data model that's based-on the idea of Inputs and Outputs that are connected via a Task. We're calling the outputs created by a Task "Deliverables" because that's by definition what a deliverable is. Inputs can be instructions, reference, glossary, TMs, or "files" that need to be transformed (includes JSON serialized XLIFF, of course).
A Task can have any number of Inputs (maybe even zero inputs if the "directive" can be defined by the metadata of a Task?), and can produce any number of Deliverables. Depending on the Task Type, those deliverables may or may not be a direct transform of an input. In the case where a Deliverable has a direct, transformative relationship with an Input file (e.g. "Charmander" turns into "Charmeleon"), that Deliverable is associated with an Input ID. Otherwise, the Deliverable is always associated with what inputs were used to create it because it's a child of a Task (that's associated with Inputs).
The idea of de-coupling inputs from tasks, that is, not dictating a strict parent/child taxonomy between tasks and files (or vice versa) is designed to make it easy for any CMS system, TMS system, or other system that endeavors to be part of a TAPICC ecosystem to be able to "map" their worldview to this data model. It is in direct response to feedback that previous data models were too rigid and in conflict with the data models of systems that TAPICC needs to connect to.
Please see a sketch of the data model below, and share your questions, concerns, and ideas. Thx!