OMR Spec - Official Submission to the LSC

[Jude Parrill]

Each individual model file in the MPD must have a standard header format.

Standard Header:
0 FILE <Filename>.ldr
0 <Individual filename>
0 Name: <Filename>.ldr
0 Author: <Author Name> [Username]
0 !LDRAW_ORG Model -OR- 0 !LDRAW_ORG Unofficial_Model
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 !THEME Theme name
0 !KEYWORDS words, more words,…,
0 !KEYWORDS words in second row, …, final words

0 !HISTORY YYYY-MM-DD [Username] Free text description of change. This can wrap to a
0 !HISTORY YYYY-MM-DD [Username] second row with the same date if necessary. However authors should lean toward writing longer
0 !HISTORY YYYY-MM-DD [Username] single !HISTORY lines(and not feel constrained to the historic 80-character limit on line length)

Where:
<Filename>: The name of the file using the rules specified in the MPD File Structure section
<Individual filename>: The name of the individual file using the rules specified in the MPD File Structure section
<Author Name>: The name of the author. Real full names (first and last) are required by the LDraw.org Contributer's Agreement
[Username]: The LDraw.org username of the author
Optional commands are !THEME, !KEYWORDS, and !HISTORY

Is it just me, or does it seem extremely redundant to include the THEME, KEYWORDS, and HISTORY for every single submodel of a model? Wouldn't it be more prudent to include this information once in the main model and let that be enough? I understand you are likely basing this off the standards used for .dat files and how each of them often include other files which themselves have their own headers. However, since the entire model is held in a single file, why does it need more than one of these? Considering most parts are often broken up into sections (which may or may not have been worked on by different authors), we don't see this translating into dat files.

And really, when we think about this logically, will a subpart have a different THEME or KEYWORDS from other sub-files? I can't imagine a case when they would. And sure, each subfile could have it's own history, but wouldn't it be much easier to understand the history of the file if it was all located in one spot. For Example:
0 !HISTORY 2011-12-01 [Person1] Created initial file.
0 !HISTORY 2011-12-02 [Person2] Updated subfile m-2aca to line up correctly
0 !HISTORY 2012-12-03 [Person3] Updated subfile m-1ba with missing part included in last update

This paints a much clearer picture the file's history than if the two updates had been put farther down in their respective sub-parts, where they're far less likely to be noticed. By including all the updates in a single place, it's easy to see who did what, when.