New header METAs proposal

[Orion Pobursky]

Starting this as a separate thread since I think Peter had some good suggestions:

Getting back to the original topic; I wanted to discover some way of annotating official parts with a tag that states what would need to be fixed if a part for some other reason is being edited. IMHO, the "needs work" sounds appropriate although it is not currently used or even intended for such use.

Maybe !NEEDSWORK could be added as a meta instead of being appended to the description and/or comments/!HELP.

Why not create a !BRICKLINK meta specifically for taking care of the mapping? Or a !LINK meta with two arguments - one for the authority (e.g. BrickLink), and the other for the ID?

[Orion Pobursky]

I like !LINK a lot. I think I'd rather use !EXTERNAL

I'm medium on !NEEDSWORK. I don't think there's enough parts in this category to warrant Yet Another META ™

I have one more suggestion:
Subcategories.

[Peter Blomberg]

Since !NEEDSWORK is mostly invisible to the user, could it be a flag on the PT? That would make it possible to add needswork flags to official parts whenever the needs are discovered.

[Orion Pobursky]

Since !NEEDSWORK is mostly invisible to the user, could it be a flag on the PT? That would make it possible to add needswork flags to official parts whenever the needs are discovered.

While that certainly is a possibility, a PT flag doesn't follow the part into distribution which I think "needs work" should. I'm pretty convinced that the current rule is the best solution.

[Roland Melkert]

I like !LINK a lot. I think I'd rather use !EXTERNAL

I too would rather see something like !EXTERNAL. eg:

Code:

0 !EXTERNAL "bricklink" "blabla"

But I'm wondering if this should be in the part files them selves. It might be easier to maintain in a LDConfig.ldr like additional file.

I'm medium on !NEEDSWORK. I don't think there's enough parts in this category to warrant Yet Another META

Isn't this kind of tag more at its place in the !LDRAW_ORG meta, maybe a new qualifier?

[Orion Pobursky]

But I'm wondering if this should be in the part files them selves. It might be easier to maintain in a LDConfig.ldr like additional file.

In Part file
Pro: The external number is searchable.
Con: The part file itself is edited if there are changes.

Separate file:
Pro: Significantly easier to maintain.
Con: Searching is more complicated.

[N. W. Perry]

But I'm wondering if this should be in the part files them selves. It might be easier to maintain in a LDConfig.ldr like additional file.

Makes sense, this is how Studio does it, FWIW.

[Peter Blomberg]

I have one more suggestion:
Subcategories.

The category is a "keyword with special meaning". I'm not a fan because any one part could be listed in many categories, but the specifications allow only one category. There are also several parts that lack a category even if similar parts have a category.

While subcategories would help organizing parts, I'd prefer a real ontology.

If the sole purpose of the category and the subcategory is to help organize the parts, why not have them in a separate file all together instead of having them as part of every single file?

How and where do software actually use the category? AFAIK LeoCAD uses a query and Stud.io use their own grouping.

[Roland Melkert]

There are also several parts that lack a category even if similar parts have a category.

If no category is given the first word (excluding ~, _, =) of the description is used as the category.

How and where do software actually use the category? AFAIK LeoCAD uses a query and Stud.io use their own grouping.

bin sorting (e.g. through filtering like in my LDCad's pbg files).

[Orion Pobursky]

There are also several parts that lack a category even if similar parts have a category.

I just checked. There are 7 parts (in the parts folder since those are the only parts that need a category) that the PT thinks don't have a category. All 7 are actually do have a proper category per the spec and the PT is wrong (probably some early bug that wasn't caught).

[Peter Blomberg]

I just checked. There are 7 parts (in the parts folder since those are the only parts that need a category) that the PT thinks don't have a category. All 7 are actually do have a proper category per the spec and the PT is wrong (probably some early bug that wasn't caught).

That's just because the category defaults to the first word of the description. Try counting how many parts have the default category when similar parts have a custom category. I just removed the last of the duplo doors from this list. Now all duplo doors should state their category as Door instead of Duplo.