0 Name: entry - needless ?

[Michael Heidemann]

It took me about ten years to realize that the 0 Name: entry is not used by any application. It is only there to identify the part and the licenses that it is under!

By reading the specs carefully for the 0 Name: entry I found in the Official Library Header Specification only the description that the 0 Name: entry is followed by the filename!
I doubt that 's\file.dat' or '48\file.dat' is a filename. It is a filename with relative path information.

For the '48' I can imagine that this is neccessary to address, as there might be a file with the same name in the 'p' folder. To know which of the files the current context is, it makes sense to add that ('48') information to the filename.

For the 's' the above mentioned is not correct, as subfiles needs to carry a 's' in the filename. So there cannot be any double file name. So my guess is that this is only added because we cannot avoid the '48' entry and by doing it this way all subdirectories of parts and p are addressed the same way.

But the above are mainly my thoughts (nothing is written about that) and so one main question still exists for me:
1) Why do we add the prefix to the filename? No application uses that line as it is not recommended in the File Format 1.0.2
2) Why does the Official Library Header Specification did not mention the use of the path prefix for 's' and '48'?

[Tim Gould]

I take the Name entry to be for us humans. So the prefix identifies where the part belongs (especially if you embed an unofficial part in a MPD).

But, if I understand right, its purpose and rules should be clarified?

Tim

[Michael Heidemann]

Yes, exactly. The current written text about the 0 Name: tag is on one hand not enough to understand and on the other hand wrong!

So a clarification is highly wished by me.

[Paul Griffin]

1) Why do we add the prefix to the filename? No application uses that line as it is not recommended in the File Format 1.0.2

Whoops. Where is that mentioned at?

I like that information as I'm on a POSIX-style OS (slashes work the other way, albeit I did see one slash going the wrong way) and the internal filenames seem to match up well...95% of the time. Except when someone puts the slash the other way and they mess up the filename case.

[Chris Dee]

From an information management perspective, it is not a good idea, IMHO, to have an object's context defined solely by its filename. I believe that information should also be included within the content of the file.

I am concerned to hear that there are errors in the Name: line of current official library files, because they shouild have all been checked programmatically prior to the release of new files. If anyone here already has a list of those errors, please email that to me and I will fix (through the Parts Tracker).

[Michael Heidemann]

Misunderstanding occur.

As fas as I can see *ALL* parts of the library like we used to have them. No Error on the parts!

The error is in the specification of the Official Library Header Specification.

It says:

Code:

0 Name: Filename.dat

Explanation:

Code:

Filename is the file name

I can not find any spec where I can see why 's\' and/or '48\' is allowed!
To all guys that works still long time with LDraw files this is not a question. They know it. But newbees not! That is my concern.

[Steffen]

All existing official files use the backslash \ currently.
The entry after Name: must not be taken literally as a filename.
It is a logic information, which must be translated into the local filesystem first.
On a POSIX system, a replacement of \ by / needs to be done.

I think we should harden the standard and fixate usage of \ as mandatory,
as this is the de-facto standard.
I think we should not allow arbitrary mix of \ or /, but instead define 1 char which is OK there,
and the only one possible currently is \ - sorry, UNIX guys :-)

[Travis Cobbs]

Official parts freely mix / and \ when specifying sub-parts on type 1 lines. That's not going to change. However, as you point out, all the Name lines currently use \. I don't have a problem with requiring them to use \, although I strongly suspect that the existing name lines are algorithmically generated by the parts tracker, since 100% consistency on non-critical items is something that's rare in the parts library due to its long and varied history.

I'd also like to point out that, except on the command line, all versions of Windows fully support / as a filename path separator interchangeably with \ (although I think UNC paths have to begin with \\, and not //).

[Paul Griffin]

Official parts freely mix / and \ when specifying sub-parts on type 1 lines. That's not going to change

Yea, /that/ was what I encountered. Why won't that change? Is that considered a major revision of someone else's part?

[Travis Cobbs]

Well, unless Chris Dee takes it upon himself to automate it, and update all existing files to be consistent (without going through the review process), it would simply be unmanageable. I guess I could be wrong; maybe that could happen.

Also, I don't see it helping software developers much. Windows-only software developers can currently ignore the difference, since both act equivalently. Software developers for other platforms have to convert \ to /, but since LDraw started out in DOS, I strongly suspect that if one separator is chosen, it will be \, so non-Windows developers will still have to do the conversion.

[Steffen]

Yes, and because of that I suggest that we harden the spec and require \ in both the 0 Name: and type 1 lines:
The POSIX guys anyway need to do the conversion, and the Windows guys anyway don't have to change something.