Draft: Introduce color_name

[CZDanol]

This PR attempts to address #80.

However, having now implemented this, I am actually quite unhappy how it ended up:

1. WIth this split, it would now be a common occurence for the material_name to be equal to both abbreviation and material_type - for exmple PETG Jet Black would get split into material_name = PETG and color_name = Jet Black. This I attempted to "fix" by adding the ability to default the material_name to the value of material_abbreviation if not present.
2. material_abbreviation can default to material_type is not present, which results in this two-level dependency chain.
3. material_name is used for the UUID derivation, so this severely complicates the implementation of the UUID derivation mechanism and makes it prone to errors
4. The UUID derivation mechanism is further complicated by the addition of the optional color_name field which now needs to be considered as well.
5. Because material_name can possibly be derived from material_type, which is an enum, it could now happen that the UUID derivation fails in case the library is not up to date and does not yet support the material_type value a tag contains.

So, actually, quite sad about this.

The only "possible" alternative I see to this would be to have three separate fields that should approximately match material_extended_name = material_name + color_name, but:

1. It would noticeably increase memory usage on the tag
2. Since all fields are actually not required to be present, there would be higher chance of a manufacturer omitting either of these fields, so overall, the data reliability would drop significantly.
3. Consumers of color_name could never rely on the color being actually there (because the manufacturer could have decided to enter just the material_extended_name)
4. What's even worse, there would be a higher chance of material_extended_name not being present, which would hamper the UUID deduction.

BFW-8775

[yanshay]

Before I can comment I need to understand what are these uuid and uuid derivation for various fields for.

I read the explanation that some fields have a uuid counterpart and if not one can be derived, but I couldn't see an explanation of use cases for those UUID's.

Can you explain or point me to some explanation that I may have missed?

[CZDanol]

Can you explain or point me to some explanation that I may have missed?

This is to be able to uniquely identify various entities in the tag everywhere. We are working on a material database (see #70) and we want to make sure that everyone can cross-link their OpenPrintTags with the data in the database, and in a decentralized way (that's why the hash-based UUIDv5, so that you could for example have a local fork of the DB where you add some filaments, but when you publish your filaments to the upstream, they all will keep the same IDs, plus if someone else adds the filaments before you, they would have the same UUIDs).

[CZDanol]

At this point, I'm really considering adding just color_name_start_pos that would reference a first letter inside material_name that denotes the color name - how about that?

[yanshay]

Not sure I fully understand the uuid, but I get it's for some referencing using uid's instead of the entire string.
Not sure why material_uuid is required (to distinguish Prusament PLA from eSun PLA at uuid level though, as if SUNLU PLA is different than Bambu Lab PLA - when Sunlu manufactures some of Bambu Lab filaments. Not to speak of product lines which will cause issues with such differentiation, but I could definitely be missing something on certain use cases.

What I don't understand even with that is why is it ok to have material_abbreviation, which is included in material_name and it is not ok to have color_name included inside material_name just the same? And adding color_name is causing issues with uuid when material_abbreviation does not?

At this point, I'm really considering adding just color_name_start_pos that would reference a first letter inside material_name that denotes the color name - how about that?

I don't really understand how this help you with uuid vs. just adding an extra color_name field, but also don't have any issues with this approach, just a bit unusual to reference positions in this type of specifications, probably prone to errors on manufacturers side. Going with that approach, since there is no specified order of information for material_name then need both start_pos and length, otherwise you assume color comes last and I didn't see that as part of the definition of material_name.
Technically for me that would work.

It is also potentially possible to add subtype using this same approach (to know what type of PLA for example) the same way, but another alternative, at least for me given the color_name_start_pos is to remove the material type and then the color name and assume the what's left is subtype. It's a bit of deduction approach to get the most critical fields in the tag but it would work. Just strange that nominal_full_length' gets a field when I'm not sure how many use it, and color_nameandsubtype` don't and every user knows both and use it every day and every time they print/purchase/filter/etc. materials.