LDraw.org Discussion Forums
[LSC Request] End of header meta command - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: [LSC Request] End of header meta command (/thread-8081.html)

Pages: 1 2 3 4 5 6 7 8 9


Re: [LSC Request] End of header meta command - Max Martin Richter - 2014-01-07

A great example for a header with unwanted informations:
Link to 2515a on PT

/Max


Re: [LSC Request] End of header meta command - Ben Supnik - 2014-01-07

Hi Tim,

I just read the header spec and it's not what I expected.

If I read the spec right,
1. if the part is a simple color alias, then by design the header should include the single sub-part reference that applies the specific color to the sub-part.
2. if the part needs work, the first file comment should describe what needs doing but
3. if the part does not need work, then the first comment is "implementation comment", describing what's going on in the file.

If we were to add a new meta to delineate the end of the header, how would case 1 work?

(A reasonable answer might be that the sub-part directive for color specification really should not be considered part of the header, I suppose.)

Cheers
Ben


Re: [LSC Request] End of header meta command - Travis Cobbs - 2014-01-07

As it happens, I'm pretty sure an algorithm can be made that can exactly determine the extent of the header. That's because the Official Library Header Specification specifies a list of the only meta-commands that are allowed to be in the header. Unfortunately, implementing such an algorithm would be quite tedious, and the list of allowed meta-commands changes over time, so the algorithm would have to be updated every time a new meta-command was added to the list. So I don't think it's reasonble to expect software authors to implement such an algorithm.


Re: [LSC Request] End of header meta command - Michael Heidemann - 2014-01-07

You already answered yourself Smile and you are right.

This whole think is not worth talking about in my eyes because it only effects the library parts.

I had to deal with this in DATHeader and also in MPDCenter.
DATHeader is, AFAIK, the first application that dealed with the header. All other application needed to just ignore this, as there is only one information of interest !LDRAW_TYPE for displaying.
Let us keep things simple. If a user build a new part he might use the official header, but I doubt.
So you can't relay on such a tag in your code if you divide the header and the body.
For MPDCenter I also had to add some more meta commands to be knows as body portions to let the header editor work there as well. Therefore i added there a special file called BODY_META_COMMANDS that is editable by the user.

So you end up for sure in detecting all those possibilities and now we add one more. Does not make sense to me as the only effect is that the first real body documentation _might_ be visible to the user.


Re: [LSC Request] End of header meta command - Allen Smith - 2014-01-07

No, it proves that making the statement optional doesn't fix the problem.

It's currently impossible to write an algorithm which BOTH reliably detects the header AND is future-proof with no additional maintenance. Considering how susceptible LDraw is to the incursion-of-real-life-responsibilities problem (myself being the latest victim-in-point), future-proof algorithms are good things.

Allen


Call for LSC Vote Re: [LSC Request] End of header meta command - Tim Gould - 2014-01-07

I suspect all real arguments have been played out here. Certainly I can't add anything. And there is enough support (I count at least four yeas) from the community to warrant the LSC getting involved.

I formally request that the LDraw Standards Commitee vote on this proposal. I will, of course, abide by whatever decision it makes and never speak of it again Smile

Tim


Re: [LSC Request] End of header meta command - Ben Supnik - 2014-01-07

Steffen Wrote:Yes, exactly. You have to admit that this is a valid counterargument against the new syntax.
If the new syntax is optional, and you anyway have to implement fallback code, then you could use the fallback code from the beginning. That proves the redundancy of the new syntax.

Hi Steffen,

Except: the old fallback code will produce _incorrect output_ some of the time (because the fallback code cannot distinguish between header comments like "this is what needs to be fixed" and implementation comments like "first outer contour of left flange").

So if a programmer cares about correctness of parsing, then the fallback code does not render the new syntax (and new code) redundant because the new code+new syntax fixes an otherwise unfixable bug.

So...I think you can make the argument, if you wish, that the cure is worse than the disease, that this is a small bug and a meta is a big deal, and that the value trade-off is not good.

But I do not think you can make the argument that the syntax does not solve a currently unsolvable problem.

@Allen: I think that not only can you not right a future-proof algorithm, but you can't even parse the headers correctly now. But the point about future-proofing is important too - even if we were to fix this bug by "fixing" the spec (e.g. just saying no comments in the headers, ever) the introduction of new directives and new metas would break parsing.

@Steffen, one last thought: any time new syntax is optional and tries to make things easier, I agree that it does temporarily make things harder for programmers (by putting a second case into the spec).

But such "let's try again" format changes also start a clock; if we hope to ever move to cleaner formatting that allows for simple parsing, better to get the extension sorted out sooner. Then later, the part library can be searched for non-conforming parts, they can be batch-updated, and eventually the optional can be dropped by a new extension. That's a long, slow process, but it's even slower if we defer introducing a syntax fix.

(That's not an argument that this is really important either, of course.)

Cheers
Ben


Re: [LSC Request] End of header meta command - Roland Melkert - 2014-01-07

I agree Ben, but I do understand Steffen's point though.

But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.

But that might raise the need to for a new 'needs work' comment like meta (it's been proposed before if I'm not mistaken).


Re: [LSC Request] End of header meta command - Ben Supnik - 2014-01-07

Roland Melkert Wrote:But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.

Hi Roland,

Right - and that's where Allen's point comes in. If a client needs a complete and inclusive list of header METAs to determine "what is the header", then we break header parsing for all existing clients every time we add a new header meta. :-(

I think the LDraw file format is one where there are:
- lots of clients and
- many clients care about only some of the information and
- the format is going to grow new features (e.g. BFC, TEXMAP, etc.) over time.

So any time parsing the file requires knowing the latest format in its entirety, that's problematic because by definition old apps don't have that info. :-(

cheers
Ben


Re: [LSC Request] End of header meta command - Chris Dee - 2014-01-08

Roland Melkert Wrote:But the only way i can think of to fix things without a new meta is to ban comments from the header all together. And use the 'permitted meta's in header' list for detecting the end of header.

But that might raise the need to for a new 'needs work' comment like meta (it's been proposed before if I'm not mistaken).
I like that suggestion better, and it would be much easier to implement formally by only updating those files that have "header comments", rather than updating _every_ file to add an end-of-header meta-statement.