Alias parts PHP script

[Orion Pobursky]

I response to complaints about my (inadvertent) use of alias parts, I wrote a PHP script that updates a model file to not use them. This could easily be extended to also handle MovedTo and Physical Colour parts. Is there any interest in this being hosted on the LDraw.org servers?

[Allen Smith]

Has any official decision been made about marking Alias parts? I am eagerly awaiting so I can exclude them from the default part library I display; that would probably make the script unnecessary.

Orion, could you attach the script to your forum post?

Allen

[Orion Pobursky]

Attached.

Note that it pings the official library every time it runs. This is so I could test it on my local machine. This isn't an issue if it were hosted on the LDraw.org servers since it would be a local file operation but outside of that I think it wouldn't be appropriate to put it out in the wild since it'll draw bandwidth from LDraw.org.

Also note that I only check official files.

[Chris Dee]

Is it too much overhead to read the !LDRAW_ORG metadata? It should always be line 4 and Alias parts will be labelled

Code:

0 !LDRAW_ORG Part Alias

I'd really like to move away from the use of an arbitrary character in the title to identify the file type.

The main discussion is in this thread.

[Orion Pobursky]

That's what my script does

[Allen Smith]

Is it too much overhead to read the !LDRAW_ORG metadata?

That should be fine. I just needed to know that an official decision had been reached.

Thanks,
Allen

[Orion Pobursky]

I don't think I really matters since Bricksmith doesn't use parts.lst. In fact parts.lst is mostly obsolete.

[Steffen]

I just want to note that no script should rely on that any of the header lines occurs in a certain line number.
"It is always on line 4" is something we should avoid.
Of course, we should stick to adopting some "normal" default order in the header when publishing parts,
but all tools should be capable of reading a file where 1 or more of the header lines is not present,
or where they are in a different order.
The header lines should more be treated like "key = value" assignments:
they convey the information

• type is xyz
  
• license is xyz
  

etc.
In which _order_ this information is communicated to a tool should be of irrelevance.

Just wanted to mention this,
applying the general principle 3.9 from here http://www.faqs.org/rfcs/rfc1958.html :
"3.9 Be strict when sending and tolerant when receiving."

[Chris Dee]

Agreed

[Allen Smith]

Implemented and checked in.

Thanks, Chris.

[Allen Smith]

Code:

0 !LDRAW_ORG Part Alias

In my implementation, I just look for the "Part Alias" substring. But I'm also trying to reconcile this with the official File Format Specification:

<type> = "Part"
(qualifier(s)) = "Alias"

Is that right?

This is confusing because "Part Alias" can't be the <type> (it has embedded whitespace), "Alias" is marked obsolete/deprecated, and the (qualifiers(s)) aren't documented at all.

And the whole thing is officially "free-format", which is a synonym for "not machine-readable".

Searching for a "Part Alias" substring is fine by me, but I never would have deduced from the spec that I was supposed to look for that.

Allen

[Roland Melkert]

The type meta can be a pain to parse indeed.

This is what I'm using at the moment:

Code:

meta: "LDRAW", "LDRAWORG", "LDRAW_ORG", "!LDRAW_ORG", "OFFICIAL", "UNOFFICIAL", "UN-OFFICIAL",

type:   "Part",  "Subpart",  "Primitive",  "48_Primitive",  "Shortcut",  "File",  "Model",  "Submodel",  "Element",  "Sub-part",  "Hi-Res primitive",  "Alias",  "Cross-reference",  "Configuration",  "Unofficial_Primitive",  "Unofficial_Part",  "Unofficial_Model"

qualifier: "Physical_Colour", "Alias"

All case insensitive, and do note the space in "Hi-Res primitive" you need to keep an eye on that while parsing.

You also need to skip an optional "LCAD" after the main meta keyword.

Hope it helps.

[Allen Smith]

The type meta can be a pain to parse indeed.

This is what I'm using at the moment:

Code:

meta: "LDRAW", "LDRAWORG", "LDRAW_ORG", "!LDRAW_ORG", "OFFICIAL", "UNOFFICIAL", "UN-OFFICIAL",

type:   "Part",  "Subpart",  "Primitive",  "48_Primitive",  "Shortcut",  "File",  "Model",  "Submodel",  "Element",  "Sub-part",  "Hi-Res primitive",  "Alias",  "Cross-reference",  "Configuration",  "Unofficial_Primitive",  "Unofficial_Part",  "Unofficial_Model"

qualifier: "Physical_Colour", "Alias"

All case insensitive, and do note the space in "Hi-Res primitive" you need to keep an eye on that while parsing.

You also need to skip an optional "LCAD" after the main meta keyword.

Bleah.

Let us assume I presently have no need or interest to fully parse this creature. I only want to know if a part in the latest official library is an alias or not. Is looking for

Code:

!LDRAW_ORG Part Alias

sufficient, or do I need to consider other permutations of this meta's apparently-tortured history?

Next problem: the official spec is missing a number of the things Roland is parsing for, including any discussion of (qualifiers), which is what precipitated this question in the first place. I would like the spec to match the library and the library to match the spec. In a perfect world, that would mean adding new stuff to the spec, removing old cruft, and adjusting the library files to match.

Allen

[Roland Melkert]

Next problem: the official spec is missing a number of the things Roland is parsing for, including any discussion of (qualifiers), which is what precipitated this question in the first place. I would like the spec to match the library and the library to match the spec.

Far as I remember I've gotten all those keywords from the specs on LDraw.org at some point(s) in time.

I kinda agree about cleaning up the meta, but the backwards compatibly friendliness of LDraw will always demand authors to keep an eye open for the old mess.

[Chris Dee]

The type meta can be a pain to parse indeed.

This is what I'm using at the moment:

Code:

meta: "LDRAW", "LDRAWORG", "LDRAW_ORG", "!LDRAW_ORG", "OFFICIAL", "UNOFFICIAL", "UN-OFFICIAL",

type:   "Part",  "Subpart",  "Primitive",  "48_Primitive",  "Shortcut",  "File",  "Model",  "Submodel",  "Element",  "Sub-part",  "Hi-Res primitive",  "Alias",  "Cross-reference",  "Configuration",  "Unofficial_Primitive",  "Unofficial_Part",  "Unofficial_Model"

qualifier: "Physical_Colour", "Alias"

All case insensitive, and do note the space in "Hi-Res primitive" you need to keep an eye on that while parsing.

You also need to skip an optional "LCAD" after the main meta keyword.

Hope it helps.

I am confused as to why you need to cater for all that non-standard syntax. The header spec (with addenda) is pretty clear, that all that is allowed in Parts is:

Code:

meta: "!LDRAW_ORG"

type:   "Part",  "Subpart",  "Primitive",  "48_Primitive",  "Shortcut", "Unofficial_Part",  "Unofficial_Subpart",  "Unofficial_Primitive",  "Unofficial_48_Primitive",  "Unofficial_Shortcut"

qualifier: "Physical_Colour", "Alias"

version: "ORIGINAL", "UPDATE yyyy-rr"

Every official part since the library was re-issued as 2008-01, adheres to this.

Is the real complaint that lack of checking of unofficial parts submitted to the Parts Tracker? As mentioned here, the submit process could use the header checking routine that is run prior to parts release. I'd appreciate more than one person's feedback on whether the rejection of submissions due to malformed headers would be a barrier to contributors.

[Roland Melkert]

I am confused as to why you need to cater for all that non-standard syntax.

The above is what I use in LDCad, but it's based on the parser of LD4DStudio, which I wrote at the dawn of the century. Back then I wasn't knee deep in the standards so I pretty much added support for all I could find.

And now it's in there I don't see the need to remove it, maybe the LDraw library don't need big chunks of it anymore, but some weird ancient old custom part someone is using might.

This is all for reading though, when writing a file the strict current standard is used.

edit: I just noticed one or two part keywords I don't scan for, thanks for pointing that out will add them

[Allen Smith]

My confusion was that some of that obsolete syntax is officialized in the LDraw.org File Format, whereas some of the information in the Official Library Header Specification is not in the File Format spec. That doesn't make a lot of sense to me. At the very least, it should only be in one place. Since the LDRAW_ORG meta is tied closely to the official library, the Header document is probably the better place. And since every file in the library is compliant, I don't really see a need to document any of the obsolete information.

Allen