LDraw.org Discussion Forums

Full Version: Are standards for official parts too strict?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6
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.
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 Smile

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 //
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

Quote: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.
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!).
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 ].
I know I should stay out of this discussion, but since I think I'm much the reason it came up, I can't.

Tim Gould Wrote:Allow small gaps in parts (sub 1sq LDU, with some discretion)

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

Willy T Wrote:... 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.

Tim Gould Wrote: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.

Tim Gould Wrote: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
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.
Philippe \Philo\" Hurbain Wrote: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
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
Tore Eriksson Wrote:
Tim Gould Wrote: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?
Pages: 1 2 3 4 5 6