Closed rmraya closed 5 years ago
Assets are already independent from Tasks. Tasks will be independent from Assets when I implement this https://github.com/GALAglobal/TAPICC-API-implementation/issues/47
Assets are currently dependent on a Job. That means, when you want to create an Asset, you are required to associate an Asset with a Job by Asset.jobId property.
If we would make Asset.jobId not required, but optional, it would mean there can be orphaned Assets. Which would break from our original idea that there is a convention that a Job is a scope of some work and there should not be orphaned Assets or Tasks.
What benefit do you see in breaking this convention? EDIT: ok I see your updated post now with the added benefit.
Independent does not mean orphan. A good implementation should track asset usage.
The same asset could be used in multiple tasks in different jobs.
You can have multiple Tasks related to an Asset already. But why would you want the same Asset in multiple Jobs? That would make sense to me only if we are talking about References, so that you can reuse the same reference across multiple Jobs. Are you talking about Asset references here?
I'm not talking about references.
An asset could be part of multiple jobs.
So you would like to have the same Asset object related to multiple Jobs. So I would say, what you are proposing is MANY to MANY relationship between Assets and Jobs. One Job would be able to have many Assets. One Asset would be able to be related to many Jobs.
Is that correct?
No, that's not correct.
Assets should be independent from jobs. There is no relationship required between asset and job.
A task can use an asset and that is the only relationship that you need. The relationship is unidirectional.
Having orphaned Assets without a parent Job would in my opinion complicate things. At least for the implementer when he would have to think about Jobs as a container of work, and at the same time he must not forget that there could be orphaned Assets flying around with no Job.
I would rather keep that convention that a Job is a container for work. But let's wait for other opinions here.
I guess my concern is also in the implementation side: all the TMSes I've been involved with have some sort of main level object (generally a "project") to which assets are attached. It might be difficult to implement free floating assets for such systems. Things would also get a lot more complicated when deleting/updating such shared assets as the consequences could span many jobs.
The only advantage I can see to an unattached asset is, as Rodolfo pointed out, when such data is shared by several jobs. But a TAPICC job corresponds (roughly) to a "project", then there is usually no sharing of source documents between projects. For example if a big MIF file is to be translated into several targets, it can be declared uniquely on a job and each target/task can share it withing that job. The only sharing across job I can think of would be reference material rather than assets.
But like Alex said, other opinions would be nice to have.
Closing for now. Feel free to post a comment if I should reopen
The same asset could be used in multiple tasks in different jobs. If they are not independent, you need to store duplicates.