Are standards for official parts too strict?

[Travis Cobbs]

A number of part authors have indicated that they feel that some (many?) of the restrictions placed on official parts are overly bureaucratic, and thus counterproductive. And while I've been a member of the LSC for many years, I am not a part author, and I don't review very many parts. So while I personally feel that the current standards are fairly reasonable, I also feel that if they're driving part authors away, then perhaps they should be changed.

So, I'd like to get feedback from part authors, but only if the feedback is polite. Orion will quite rightly not put up with this thread turning into a flame war. I'm looking for honest feedback from current part authors about the requirements for official parts as they stand now. More specifically, I want to know if there is a feeling that certain restrictions should be removed.

If the results are such that I feel it's warranted, I'll start an official LSC discussion in the LSC forum. (This thread is here in this forum so that I can get feedback from more than just the current 5 members of the LSC.) If the vast majority of the results are that things are OK, I won't. And I'll be honest: even though I promise to start the discussion if I feel it's warranted, I can't make any guarantees about what the results will be, since I'm only one member of the 5-member LSC, and LSC procedures for the current LSC state that 2 NO votes are enough to defeat any proposal. And depending on what the requests are, I may even be one of the hypothetical NO votes. Actual change will require that no more than one of the current LSC members is against the proposed change.

[Tim Gould]

Hmmmm. Thanks for opening this up.

There's a few things I'd like to see weakened. Not sure how many of these are LSC or PT controlled but the LSC has ultimate control over the format. There's a good chance I'll think of more

The ones that spring immediately to mind are:

Allow small gaps in parts (sub 1sq LDU, with some discretion)

Allow duplication of optional lines (this one would be really, really good IMO)

Allow comments in parts of form 0 or 0 //

[Willy Tschager]

This issue pops up every now and then. The SteerCo has discussed this also endless times and our position is that we do not compromise on quality. Since there is the "Needs work" rule in place:

http://www.ldraw.org/Article398.html

If the part is good enough for public use, but has some deficiencies that need to be addressed, the text " (Needs Work)" (without the quotation marks) can be added to the end of the description.

we think leaves enough room for mock-ups and the like.

w.

[Philippe Hurbain]

Like Willy I feal at ease with present situation, with the help of "Needs Work" that allows to post useful parts even if they are not perfect. Yes, formal formating was a chore for a messy, absent minded guy like me. But I feel it's really useful to have strict standards that can prevent the triggering of software bugs... and fortunately the relief came through DatHeader that takes care of most of this nitty-gritty stuff!!! (Thanks again, Mike!).

[Steffen]

I am fine with the current standards.

Allowing gaps etc. in parts is something I would not want to see happen.

The (Needs Work) suffix is a good compromise, which allows to let out parts which still need to be worked on.

I especially appreciate the introduction of the !LDRAW_ORG type header element.

I have 2 points where I would like to see a rules relaxation, both refer to the !HISTORY element:

(1)
I never understood the distinction between [...] and {...}. I can not imagine any kind of software which would
rely on that. Even if such software existed, and it would parse that stuff, it would need to connect to the ldraw.org site to make the strings it finds any useful. And as it anyway has to do that, it does not matter whether it found those strings between [...] or {...}. The mix of both to me makes the !HISTORY lines harder to read, and this way one of its major purposes is spoilt.
Suggestion: drop the requirement for using {...}. Just use [...] always.

(2)
Current rules try to force authors to NOT use a tabular !HISTORY like this:

Code:

0 !HISTORY 2011-10-01 [Steffen]                   did something
0 !HISTORY 2011-10-02 [xyz]                       did something else
0 !HISTORY 2012-01-01 [SomebodyWithALongUsername] did another thing

, they instead try to enforce

Code:

0 !HISTORY 2011-10-01 [Steffen] did something
0 !HISTORY 2011-10-02 [xyz] did something else
0 !HISTORY 2012-01-01 [SomebodyWithALongUsername] did another thing

This is a to me completely unnecessary complication in the specs,
as any piece of software could easily skip all whitespace after the ] to get to the start of the comment line.
To me, the !HISTORY lines are mostly intended for human-reading. I want to quickly see what happened
or who did it, and a tabular layout helps here. I want to be free to use or not use it at will.
Suggestion: allow any number of whitespaces after the ].

[Tore Eriksson]

I know I should stay out of this discussion, but since I think I'm much the reason it came up, I can't.

Allow small gaps in parts (sub 1sq LDU, with some discretion)

Believe it or not, in this case I agree with Willy:

... our position is that we do not compromise on quality. Since there is the "Needs work" rule in place <snip>, we think leaves enough room for mock-ups and the like.

Gaps and (at least bi-color) overlaps in patterns are actual errors and mistakes made by the part author, that in deed effect the output from renderers, viewers, and editors. In most cases, such errors are relatively easy to locate and correct. If not, there's still the "Needs work" option.

Allow duplication of optional lines (this one would be really, really good IMO)

This issue is new to me, so I cannot say anything for sure. But if it makes no difference to the output, and it would be really, really good in any sense, it should be allowed. Focus should be set on the output quality, not academical formalities.

Allow comments in parts of form 0 or 0 //

Here is the major source of at least 90% of my annoyance. This is not a matter of output quality, it's a matter of the part author's personal touch, personal taste, personal expression vs the current LSC's temporary opinions and the PT reviewers' personal taste. As a part author, I cannot set my footprints in a part file in such a way it effects the output or endangers the functionality of any LDraw related program. Of course not. But at least I wish to format my "blocks of data" in my personal way, I want the freedom to use whatever spacers I wish and conclude the part file in my way, ie the same way JJ did. Once again, of course without endangering the functionality of any LDraw compatible program.
Even though it's most hypothetical it ever will mess up any LDraw program, there is still a very small risk that this comment will cause problems:
0 My comment
Because any newly made program that will use the "0 MY" meta-command should use "0 !MY" instead. Nevertheless, I think it's a good idea to keep this kind of comments away from new parts, and when updating older parts, change them to:
0 // My comment
just to be on the absolute safe side.

Single "0" line and "0 //" are truly legal LDraw lines, as well as blank lines. Any LDraw software unable to handle (ie, skip in this case) these kind of lines, is not at all LDraw compatible even to the very basics of the LDraw format. How a part author uses these legal, basic LDraw lines, should be entirely up to the author. If an author wishes to make five blank lines in a row as his/her personal footprint in the part files, it is none of the reviewers' business. The LSC and the reviewers should focus on the quality of the output and not rule over the authors' personal style.

http://www.ldraw.org/Article398.html
"UserName is the author's LDraw username. It needs to be optional for those past authors that still don't have a username."
should be changed to:
"UserName is the author's LDraw username and is optional."

So, the bottom line is: Don't compromize with the quality, but grant the authors freedom to add their own personal touch to the part files, as long as it is legal LDraw code tht don't mess up any LDraw software.


/Tore

[Tim Gould]

Actually, I have one (related) point I'd like to see raised:

Could (NW) be allowed as a valid substitute for (Needs Work). To make way for long parts.

[Tore Eriksson]

I feel it's really useful to have strict standards that can prevent the triggering of software bugs.

That does not make any sense. There is already a strict standard for the LDraw file format. This itselt is a 100% guarantee to prevent the triggering of errors. Any software infested with such blatant bugs that it cannot cope with correct basic LDraw syntax needs to be debugged. I see no reason for the standards for new official parts is so much stricter than for the generic LDraw files. What is perfectly legal LDraw code for older parts and for old and new models - that is, any LDraw software just got to be able to handle it correctly anyway - is illegal for new parts.

So, yes of course I agree. That's exactly why I see no reason not to weaken the parts standard, to harmonize it to the perfectly sufficiently strict generic LDraw file format. (Except of course for MPD, inline POV code, and META-statements that have nothing to do in official parts files.)


/Tore

[Tim Gould]

I assume Philo was referring only to the header information. In which case it will parse fine on older software, but has additional information for newer software in a way that is easy for them to parse. And Datheader does all the heavy lifting so it's not like it's a challenge.

There's a standard rule for file parsing that says you write pedantically, but read flexibly. Having a correctly formatted header is part of this process.

Tim

[Allen Smith]

Allow comments in parts of form 0 or 0 //

Single "0" line and "0 //" are truly legal LDraw lines, as well as blank lines. Any LDraw software unable to handle (ie, skip in this case) these kind of lines, is not at all LDraw compatible even to the very basics of the LDraw format. How a part author uses these legal, basic LDraw lines, should be entirely up to the author.

Being a software author not a part author, I don't have the context on the debate here. Are you saying that lines consisting only of "0" ought to be legal but are currently forbidden? That any comment line beginning in 0 should be allowed (even though you think they're a bad idea)? That blank lines ought to be legal but currently aren't?

[Orion Pobursky]

Allow small gaps in parts (sub 1sq LDU, with some discretion)

I disagree with this except for the cases where a "Needs Work" is applied.

Allow duplication of optional lines (this one would be really, really good IMO)

Please elaborate. Most modern editors don't even use these except for LDView which uses them for smooth curve detection.

Allow comments in parts of form 0 or 0 //

I never understood why we care about comments in part files to begin with. I do think that 0 // should be preferred except for the bare case of just 0

[Tim Gould]

re. gaps - I'm in the minority (of one it appears) so not going to argue that point!

re. optional lines - the most common problem I can think of is at the intersection of certain round prims, and the rest of the part. Sometimes it would just be way, way, way easier to allow for duplication of optional lines. It's not a dealbreaker, but since the question was asked I'm happy to throw it out there.

re. comments - "0 blah blah blah" is the traditional comment line and the restriction to "0 // blah blah blah" just strikes me as overkill. Metas are meant to start with ! anyway so the margin for risk is slim indeed.

And comments are _very_ useful when the part is either redesigned (for whatever reason) or used as the foundation of another part. I've nearly torn my hair out when working from/with parts with a block of commands and not a single comment.

Tim

[Tore Eriksson]

Being a software author not a part author, I don't have the context on the debate here. Are you saying that lines consisting only of "0" ought to be legal but are currently forbidden? That any comment line beginning in 0 should be allowed (even though you think they're a bad idea)? That blank lines ought to be legal but currently aren't?

Yes and no to all questions.

We have to distinguish between the generic LDraw file format standard and the for some reason lot stricter LDraw parts format standard. I have been very, very upset and may not have gotten everything correctly, but this is how I percepted the last few days. Anyone correct me where I am wrong.

Only "0" is illegal in new part files - but not a reason for a Hold vote in the PT. For any other LDraw file, "0" is perfectly alright.

Single blank lines in new part files are ok I think, but if a reviewer dislikes the number of blank lines or any other purely cosmetic layout structure issue, he may Hold or edit the part files in question, based on personal taste.

A comment line beginning with just "0 " and not "0 // " is such a bad idea that not even I would endorse it. This was the original LDraw standard, but with the growing number of META-statements, there is a risk that sooner or later it will cause a conflict. (Any LDraw compatible software should assume that if it doesn't recognize it as a known META, then it is a comment and the line is just ignored by the program.) In LDSWITCH for example, I "comment out" line types 1 through 5 with a single "0 ":
0 1 4 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
but this is in model files, not in part files. Just telling you so you won't let the program spit out errors...


/Tore

[Tore Eriksson]

re. comments - "0 blah blah blah" is the traditional comment line and the restriction to "0 // blah blah blah" just strikes me as overkill. Metas are meant to start with ! anyway so the margin for risk is slim indeed.
Tim

Yes, I think you are right when it comes to the margin for risk. But yet, now that I've gotten used to look for "0 // " or "0 REM ", it's actually easier for me as a human to spot the comments meant for humans to read, than it was before this reform.


/Tore

[Steffen]

I think the story behind the 0 vs 0 // goes like this:

At the beginning, there were comments starting with 0.
Then, new statements got used like
0 BFC
0 LSYNTH
0 L3POV
. At that point of time, new keywords would look like
0 XXX
always. So to evade the danger of clashing with a future keyword, people
started to write comments like this
0 // blablabla
I think that at that time, that was a clever idea.

AFTER that, new keywords were introduced of the form
0 !KEYWORD
which avoided the danger of keyword vs. comment clash by the "!".

This results in that nowadays 2 techniques are present in our files at the _same_ time
to avoid that clash:
(a) keywords are preceded by a !
(b) comments are preceded by a //

We could in fact think of relaxing the rules a bit to allow comments without // again,
but then comments never must begin with "BFC" or "LSYNTH", and that again makes things complicated.
For example, this
0 BFC is something I will do later in this file
will create a parse error. And this one as well:
0 LSYNTH is a quite great tool I like a lot
Thus, the new rules would have to state that and forbid certain comments.
That's ugly. This is much simpler and easier to remember:
Just start real comments with 0 // - at least in official parts.


PS
uh, and separator lines, consisting just of a
0
should of course still be possible and allowed.
That some files currently instead write
0 //
is due to the fact that DATHeader for some time brute-forcely replaced all comments 0 by 0 //,
even empty ones. For empty
0
lines that never was a requirement.

[Philippe Hurbain]

Could (NW) be allowed as a valid substitute for (Needs Work). To make way for long parts.

Agreed!

[Jude Parrill]

I actually agree with Steffen's 2nd point here. I've always thought it would increase the read-ability of the DAT/Head to have better formatted History lines. To me, I see to reason why any software would use these lines, and it seems like, as he says, they are meant to be human-readable to provide information about who did what to the file.

[Steffen]

Regarding the (NW) suffix, I would like to suggest a different approach.

I find (NW) somewhat cryptic, and non-parts-author users will be the same way.

I think that we're abusing the title here for something which instead is a property of the file,
similar to !LDRAW_ORG file type and !LICENSE.

Thus, I suggest to instead of suffixing the title with (Needs Work) or (NW),
we should introduce a new keyword

0 !FILE_STATUS

, followed by a list of properties of the file. One could be:

0 !FILE_STATUS Needs_Work

Later, we might come up with more different ones like

0 !FILE_STATUS Mockup

I think we should try to avoid to cram such meta information into the part title,
as this additionally will mess up inventory lists of builders.

[Orion Pobursky]

I like this idea but none of the LDrae compliment programs use all the header info. Additionally having "Needs Work" in the title alerts modellers that the part has some sort of issue.

[Tim Gould]

Yeah. It was actually my first thought but I discounted it for Orion's reason. The NW is there for potential part authors so they need easy access to it.

Tim

[Travis Cobbs]

I agree that it needs to be in the title where modelers can see. For that very reason, I think (NW) may be too cryptic.

[Travis Cobbs]

Unless I'm reading something wrong, the use of {} for real names and [] for usernames is intended to make it obvious what's inside the brackets/braces.

Also, while the samples don't tabulate the HISTORY lines, I couldn't find anything in the header spec forbidding that. Do reviewers hold parts due to tabulated HISTORY lines? Did I miss the text somewhere that makes it illegal?

[Chris Dee]

Yes, that is the correct interpretation of the braces. There are authors who have affirmed the CA, but who never signed up to LDraw.org, so don't have UserNames. The header checker on LDraw.org uses the braces to know what list to validate against. There are a couple of special cases - {LEGO Universe Team} and {LEGO Digital Designer}.

Nothing forbids Steffen's suggested tabular padding of the !HISTORY lines, but when I have needed to admin-edit the headers I have usually removed them. The !HISTORY lines are "history", and it seems somehow wrong to change history. I don't have particularly strong feelings either way, but the un-tablulated format is what what I had in mind when I developed the header spec, even if it is not explicitly stated. I don't think I have ever seen a HOLD for badly formatted !HISTORY and would challenge it if I did.

[Steffen]

Actually, I always found myself quite disappointed when Chris removed the tabular formatting
from my submits.
I do not really see Chris' point of "not changing history", as inserting spaces there really is not something
carrying semantics.

My request is to allow that tabular formatting,
to extend the spec so arbitrary spaces may follow the ],
and ask Chris to not remove tabular !HISTORY submittals formatting, pleeeeeze...

[Chris Dee]

If that's the way we want to go, it should be possible to programmatically add spaces as part of the release process, because the headers get re-written anyway to add the "[PTadmin] Official Update YYYY-NN" !HISTORY line.

Now waiting for someone to raise the old "extra bytes to download" argument :-)

[Allen Smith]

I am not a part author. I am, however, capable of some clerical-type contributions which would probably be useful to the community. But I've never attempted to even BFC a part.

Unfortunately, in my perception, the Part Tracker/review process is to part authoring as Lugnet was to LDraw communication. Lugnet worked, it did some things very well, and it was comfortable to many people who "grew up" with it, as it were. Unfortunately, it was also tremendously intimidating to the unitiated—so much so that they didn't bother contributing.

The trouble is that I've heard too many demoralizing Part Tracker stories: A person who fixed a bowtie quad, submitted the fix, and then saw the part sit for four years with a hold because other pre-existing bits of it were no longer in conformance with current standards. A person whose first part waited for years in the certification tango. A person who got fed up with the whole procedure because his part got nitpicked to death.

Those are bad things. They cause the library as a whole to be of lesser quality, they alienate contributors new and old, and they encumber everything with so much inertia that it's impossible to conceive of ever advancing the state of the art (for example, a 100% BFC-compliant library). I don't feel like I can contribute under such a system; all it would do is increase my blood pressure.

Please don't misread all this. I'm constantly in awe of what LDraw part authors and part reviewers accomplish. I'll never attain that kind of skill. But I bet there are people lurking out there who might just try, if didn't feel like such a Sisyphean task. At the very least, I know there is at least one person—me—who would happily do things like fix !CATEGORYs, if only I had hope of seeing the fruits of my labors shipped in a few months rather than be trapped in a years-to-decades morass of quibbling about unreleated details.

About all I've done in the post so far is gripe, so I'll try to redeem it with an semi-serious suggestion: make the Part Tracker a wiki, or at least more like Wikipedia. Make it so anyone who cares can contribute meaningfully, and anyone who loves minutae can make tweaks personally rather than holding "hold" votes over the original author's head.

I know that suggestion trades one form of complexity for another. At the same time, I think the pendulum has swung too far in the direction of roadblocks. I don't want to see the part authorship community ossify.

Allen

[Chris Dee]

About all I've done in the post so far is gripe, so I'll try to redeem it with an semi-serious suggestion: make the Part Tracker a wiki, or at least more like Wikipedia. Make it so anyone who cares can contribute meaningfully, and anyone who loves minutae can make tweaks personally rather than holding "hold" votes over the original author's head.
Allen

I'm glad you label this as "semi-serious", otherwise, it sounds like you don't appreciate how much functionality is built into the Parts Tracker to track dependencies, provide search and filtering capabilities and most importantly manage the parts update process. If the files were hosted on a wiki (where they could change at any moment in time, with no mechanism for identifying them as "ready for release") means that building a stable update of over 450 new parts including over 750 files (as has been the case for each of the last 3 updates) would take substantially longer than the few hours it does at the moment.

[Steffen]

Hello Allen, thanks for your thoughts. Some from me:

Regarding the treatment of submits to the parts tracker, there's not much difference between
a Wiki and the current implementation: anybody wanting to edit a part can do that (just become an author).
That would be the same on a Wiki. However, the point is: "which methods to you apply to avoid errors?".
In the Wiki, you would have to use some mechanism as well to prevent errors from slipping in.
An example, just from tonight: the origin and orientation of a previously official file got changed:
http://www.ldraw.org/cgi-bin/ptdetail.cg...s/4183.dat
This always can slip in and can only be found if someone reviews the parts.
You would need that process as well in a Wiki-like system, before a part can get released.
Thus, usage of this process cannot be used against or towards the PT or a Wiki.

Regarding the review process, I disagree with you that it hinders us in publishing parts:
Look at the upcoming release: it will include far over 1000 parts,
thus proving the process to be productive.
However, there was a lack of parts releases in the past years. This led to a big todo pile
accumulating on the Parts Tracker. Thanks to Chris' efforts to increase the parts release frequency,
we were able with coordinated power to bring down this pile, look at the history graph:
http://www.ldraw.org/cgi-bin/pthist2.cgi?h=10&i=15
You can clearly see there that the lack of releases has made the mountain grow.

[Allen Smith]

I'm glad you label this as "semi-serious", otherwise, it sounds like you don't appreciate how much functionality is built into the Parts Tracker….

Yes, I realize the Parts Tracker is a custom application with important irreplaceable functionality. I do hope you didn't infer any intent to diminish the work that went into building the software, to overlook the management features it provides, or to denigrate your efforts towards keeping all this running smoothly. I appreciate all of them deeply.

The "serious" part of my concerns are:

• Does the part review process, and to a lesser extent its interface, dampen the enthusiasm of potential contributors?
  
• Could a model in which the reader, rather than the author, is responsible for the content's correctness ultimately produce high-quality products with less friction?
  

Here's an example I've been watching:
Minifig Helmet Visor Ice Planet

This part has spent nearly 10 years on the part tracker.

It took 8 weeks to attract its first three certifications.
It then sat dead for 6 months waiting for…something. Maybe subparts. During that time, the helmet it fits on was apparently repositioned.
Someone then put a Hold on it, complaining that it too needed to be repositioned. Note: this person did not just make the adjustment.
The part then suffered 8 years of total inattention. We might presume the original author had moved on to more fulfilling hobbies.
On the eve of 2012, a kind soul shifted the part as recommended. Naturally, existing certification votes were deleted. The original three certifiers never resurface to vote for re-certification.
Two days pass, and the part gets its second Hold, this time complaining about comments no user will ever see or care about.
The part is re-submitted without the offending comments.
The part then collected two certifications prior to the 2011-02 release. It sits today awaiting admin review, which I can only hope means it will finally arrive in users' hands in the next release.

Can we honestly say this is inspiring people to participate? Is there really nothing which can be done to improve situations like this? (These aren't rhetorical questions, by the way. They are offered in the spirit of continuing the conversation.) I honestly don't mean to accuse anyone with this example; to reiterate, I have the highest respect for people who make and review parts. I just feel like this example demonstrates that something isn't working quite right.

Allen

[Tim Gould]

Hi Allen,

I do share your overall opinion. As I've said many times before I think there are too many holds given where novotes would be more appropriate, and similarly I think that sometimes a quest for perfection (even given Needs Work) should never be considered more important than a quest for decent, functional parts.

But I have to note that parts like the visor represent the exception rather than the rule. Even given my tantrum. The ones that go through smoothly show up more rarely on the radar since they usually shine for a few days, and then vanish from recent activity, certified and awaiting release.

Tim

[Steffen]

Hi Allen,

well, there had been some days where there were disagreements on the parts tracker:
Some people didn't want their files to be touched by others.
That's probably the reason why in the particular case you mention a hold vote was placed,
instead of simply immediately fixing the flaw.
After these conflicts had happened several times, this had frustrated both sides:
- people who wanted to fix other parts no longer did, because they were frightened to step on someone's toes
- parts authors were frustrated because their parts received hold votes.
After those days, the rule was established that if no action on a part happens for some time,
anybody is free to fix it.
Those days also were the times where the parts releases no longer occured regulary,
and this led to many parts piling up on the PT (see my post http://forums.ldraw.org/showthread.php?t...05#pid3905
below explaining that).
For the particular part you mention, this is probably simply the cause why the progress of
the part you mention was so sloooooooow. There were just too many other parts to take care of.

I really suggest that you have a look at the parts tracker history at
http://www.ldraw.org/cgi-bin/pthist2.cgi?h=10&i=15
before continuing the complaints. You can see from there that the review mechanism is indeed
working quite well, and that in the near past we have managed to fix and release literally hundreds
of files.

That just one particular part you've been waiting for was not among them is sad,
but many people maybe were happy because of other parts.

I myself was quite sad for a time to see my own files sit around for 8 and more years now.

My suggestion to you is to ask you to join our forces.

Become a parts author and go fix the problems of the files on the parts tracker
which currently carry a "hold" vote.
Or become a parts reviewer and check the files for errors. Cast a CERT or HOLD vote to bring things forward.
From my point of view, this will bring us more advantage than thinking of replacing
(a) the server software or (b) the reviewing process with something else,
which again will bring its own problems, and which will hold up things here
as it would require to change many, many, many things.

Repeat: look at this http://www.ldraw.org/cgi-bin/pthist2.cgi?h=10&i=15 to see our progress.

[Greg Teft]

Personally, I put a lot of thought into the parts I've created and am creating.

For many this is a hobby, not a career, and the diligence of the checkers and Tim (I didn't realize he's the only admin) is commendable. I might cringe when I see those little red boxes, but if some cares enough to find an error, I care enough to rectify it. I feel bad about some of the stupid goofs I've uploaded, and a recent comment actually caused me to rethink my initial approach to a detail and do something better.

On the other hand, this is a hobby, and the world won't end over small details.

I do think the following are critical errors - overlaps, noticeable gaps, convex quads. Bow-Ties are gross. Some gaps due to primitive scaling will occur.

As far as restrictions, I didn't know that the last '0' line went out of fashion until recently, but no one's commented on it so far. I always thought of it as a footer.

I'd like to see the upload filter catch duplicate lines, trim trailing white-space, replace 0. with . and -0. with -. (to make smaller files).

I'd like to see the description line be allowed to be longer, although not sure what would break as a result.

As a programmer, I like the '0 // comment' line style.

[Tim Gould]

Tim (I didn't realize he's the only admin)

*ahem* Chris is the admin.

[Steffen]

> On the other hand, this is a hobby, and the world won't end over small details.

Nobody prevents you from downloading unofficial parts with a "hold" vote on them.
The hobby is not spoilt, you can use them as you like.
But to be released and become official, the part errors need to be repaired.
It's that simple.

[Tim Gould]

No it's not 'that simple'. There is no absolute standard of errors, there is no absolute standard quality of parts. There are minimums but there are plenty of 'holds' that go on for parts above the minimum standard, some that everyone agrees on but some that offer debate. We pick and choose what details we add and we allow small discrepencies when the library will benefit. Similarly there is ample flexibility on how we choose, or choose not to use primitives, especially rect and box ones.

Tim

[Orion Pobursky]

Not to mention that there is significant disagreement regarding limiting file size, how many primitives is too many, and stud orientation (just to name a few things I've argued about).

[Greg Teft]

oops, my bad, sorry Chris

[Michael Heidemann]

I just saw this

Code:

is due to the fact that DATHeader for some time brute-forcely replaced all comments 0 by 0 //,
even empty ones. For empty
0
lines that never was a requirement.

and like to leave my (author of DATHeader) comment.

The 0 at the start of the line indicates this line to be a comment. The first word that follows this 0 (separated by a white space) might be a comment or a Meta command.
To indicate that the content of the line is a comment and not any file processing directive the // has been choosen.
DATHeader see that it is not a meta command and therefore it has to be a comment, so add a //. It is that simple.
Just do not use a single 0 on a line, instead leave that line blank and the result is perfect for all

It is just coded what I read in the specs:
Body Meta Commands

Code:

Only the following meta commands are permitted in the body of official parts:

    0 // style comments
    BFC CW
    BFC CCW
    BFC CLIP
    BFC CLIP CW
    BFC CLIP CCW
    BFC NOCLIP
    BFC INVERTNEXT

Taken from http://www.ldraw.org/article/512.html#metabody
I (or in that case DATHeader) does only force things that are discribed in our standards!

If that is not the case, please drop me a note (or even better - post in the forum) so I will change DATHeader accordingly like I have done now for some years.

cu
mikeheide

[Travis Cobbs]

I think that DATHeader should have special handling of empty 0 lines (including ones with a 0 followed by only white space). I feel it should replace them with empty lines, not 0 //. Additionally, it might be good to warn the user that they are no longer allowed in official parts.

[Steffen]

I think the spec has a glitch here.
Lines just consisting of a 0 followed by whitespace should be allowed to exist IMHO.
People use these as separating entities sometimes, and they are not as volatile as just empty lines, as these easily get slurped away by tools.
And there's especially no need to add // to them, as these are omly intended to clearly
mark a comment, and distinguish it from (potentially future) keywords like 0 BFC

[Allen Smith]

I agree with Steffen, a line consisting only of 0 is harmless. Any attempt to exterminate them would be a misdirected use of time.

Allen

[Steffen]

+1

[Orion Pobursky]

I agree and if we really wanted to we could just legitimize them via spec. However, this to me is pointless.

[Travis Cobbs]

I personally don't care one way or another about empty 0 comment lines. However, I thought that they had been intentionally disallowed in new parts by a previous LSC. (Note: it's perfectly legitimate for the current LSC to reverse a previous decision, but I don't think it's a good idea to be doing so unless there is clear cause to believe that the previous decision was made in error, as oppsed to each year having the LSC membership tweak things to their liking.)

[Steffen]

when the removal of 0 lines isn't documented anywhere, I think it is legitimate to assume that forbidding them was an unwanted spec glitch.
as far as I remember the discussions of those days, the special case "a single 0 on a line" was intended to be explicitly allowed, because some people use it as a separator

[Travis Cobbs]

Note: in my text below, "NULL comment" means a 0 on a line all by itself.

This was discussed in early 2008 by the 2007/2008 LSC, when Chris Dee (as Part Admin, not LSC member) asked if we really wanted to disallow NULL comments, in particular regarding the one that shows up at the end of many part files. The only person in the LSC that said anything (William Howard) stated that he felt the final one should either be disallowed (which is what happened), or it should be required in all LDraw files (which he didn't feel was practical). No one else on the LSC commented further on that issue (as far as I can tell). In my personal case I believe this was because I didn't care either way, and presumably in the case of the other members it was either because they didn't care, or didn't like NULL comments.

We as an LSC were definitely aware that we were disallowing NULL comment lines in official part files, though.

[Max Martin Richter]

My opinion is, that we shouldn't make any exceptions here. This would only blow up specs and make it much more complicated to come into part authoring for a newbie.

[Steffen]

ok then, i'm fine with how things are right now

let me just add 1 more note: the mentioned discussion allows too many misunderstandings.
it leaves too unclear which things are syntactically _required_ and which are rules for _official_ parts.
and it discusses the options "forbid NULL comments" or "require NULL comment at the end of each file", but the option "allow it anywhere to be in a file" is a little underrepresented.

[Michael Heidemann]

After reading all the related comments so far I think it will be best to follow the suggestion of Travis:

Code:

replace them with empty lines

So I try to implement the following rule
line starts with 0
- yes -> no other characters beneth whitespace are on that line -> yes -> remove '0' but keep crlf of that line.

Code:

it might be good to warn the user that they are no longer allowed in official parts.

DATHeader is not designed to tell the user what has changed. That is the task for this forum and the official specifications.

If someone is strictly against this behaviour of DATHeader please rise your word as answer to this post please.

[Orion Pobursky]

The problem with this solution is that MLCad removes blank lines (unless this is fixed by a later version that I haven't tred)