This is a good place to start talking about what we design for code, and what we design for humans.
I think we can make a distinction here, such that we can escape the burden of metadata deficiency when designing for code, along with having the freedom to include as much as is necessary and relevant for humans.
For example, we could export Quicktime versions of each asset as we are today
..but then also integrate them into a
/dailies folder. The Quicktime file in this folder can then contains all information relevant to the particular asset.
The human-facing integrator would then be the one to decide which of the available Quicktime video(s) are relevant for dailies.
This way, we gain the advantage of absolute paths with no duplicity, along with fully qualified filenames where relevant. Win-win?
You're right, but that's not exactly what I'm proposing we do.
Each family is a contract, it specifies in which shape and form content must be formatted as in order to qualify as the family, such as a
model. If the content is formatted in such a manner that it conforms to the
model contract, then it is a
model, otherwise it is not.
If content then is picked up as a
model where it should not have been, such as when located within content qualified as
rig, then the contract of
model is at fault and will need to be updated. For example, it could include that the content must be an assembly.
The goal is to loosen the restrictions on what has to be done in order for the pipeline for function, and at the same time gain better control and specificity into what a family of content actually is.
I can imagine people using tools that are not proprietary to manage references in a scene
That's a good point, but we can't realistically design a pipeline to encompass all possible third-party tools out there.
The idea is that, with a well-defined pipeline, these tools should be trivial to implement yourself. Isn't this what a pipeline is for to begin with?
Other than that I know many artists who prefer to work with the namespaces hidden in the outliner who might be bugged by having it removed as information after the namespace.
I won't dignify this with an answer.
Plus there are actually formats of exporting that ditch namespaces resulting in solely output of rig_GRP.
We are in control over how things are exported, this isn't a problem.