[LSC Request] End of header meta command


[LSC Request] End of header meta command
#1
I think it would be really nice to have a meta command to indicate the end of the official part header information (especially) but also headers in general. Just something simple like:
Code:
0 !ENDOFHEADER

That way codes like LDMakeList of LDFind can know which comments are useful notes for the header (eg. in a needs work file) and which are just separators of the different part components (eg. 0 // Studs).

Of all the meta commands ever this one (hopefully) should be the easiest Smile

eg.

The ENDOFHEADER meta-command indicates that the header has ended, and that any software that processes the header can stop looking. It is not required.
Code:
0 Brick  1 x  4
0 Name: 3010.dat
0 Author: James Jessiman
0 !LDRAW_ORG Part UPDATE 2003-02
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CW

0 !HISTORY 2001-10-26 [PTadmin] Official Update 2001-01
0 !HISTORY 2002-05-07 [unknown] BFC Certification
0 !HISTORY 2002-06-11 [PTadmin] Official Update 2002-03
0 !HISTORY 2002-12-12 [hafhead] New subparted version
0 !HISTORY 2003-08-01 [PTadmin] Official Update 2003-02
0 !HISTORY 2007-06-06 [PTadmin] Header formatted for Contributor Agreement
0 !HISTORY 2008-07-01 [PTadmin] Official Update 2008-01

0 // This file has been updated often
0 !ENDOFHEADER
0 // Include the sub file
1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\3010s01.dat
0 // Add a quad on top
4 16 -40 0 -10 40 0 -10 40 24 -10 -40 24 -10
0
Reply
Re: [LSC Request] End of header meta command
#2
Yes, such a marker would help a lot to sort the comments in the file. But the only comments that are useful are at "Needs work" parts. As there has to be a comment telling us what is not correct with the part. All other official parts can stay like they are.

LDFind doesn't care about where in the file the data are stored. The whole file is scanned. As LDFind also should be usable with unofficial files i can not rely in any case on our official standards regarding the header Smile
Reply
Re: [LSC Request] End of header meta command
#3
The lack of such a meta command is a tremendous headache. It would make my life easier if it were mandatory and the whole part library had it.

Allen
Reply
Re: [LSC Request] End of header meta command
#4
That would be even better.

I've been calling the header done at the end of file, appearance of this meta (which never appears, but the code is there), or the first occurence of a non-type 0 line.

PS. You might have missed it, but could you send me any or all XML files you generate.
Reply
Re: [LSC Request] End of header meta command
#5
Tim Gould Wrote:I've been calling the header done at the end of file, appearance of this meta (which never appears, but the code is there), or the first occurence of a non-type 0 line.

So why to we need a new meta? The end of the header is already defined as per above (minus the new meta).
Reply
Re: [LSC Request] End of header meta command
#6
One problem is in comments before start of body, that are mistakenly integrated to header.
Reply
Re: [LSC Request] End of header meta command
#11
I feel an extra meta is somewhat over kill.

Why not use a double empty line or something or some other pattern.

Or move a mandatory header meta to the bottom, so you know the header ends after that/those line(s).
Reply
Re: [LSC Request] End of header meta command
#7
Because it's ambiguous. Not all type 0 lines are header info.
Reply
Re: [LSC Request] End of header meta command
#32
That could also be solved by creating a new line type just for headers.
Reply
Re: [LSC Request] End of header meta command
#34
That's a good solution. But you've seen how hard it is even to get a simple optional meta added. Do you really think we're going to add a new linetype?

Wink
Reply
Re: [LSC Request] End of header meta command
#8
What Philo and Allen said. See eg.

Code:
0 Animal Rat
0 Name: 40234.dat
0 Author: Philippe Hurbain [Philo]
0 !LDRAW_ORG Part UPDATE 2009-02
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CCW

0 !HISTORY 2009-09-03 [PTadmin] Official Update 2009-02

0 // Shape acquired with NXT-based 3D scanner
0 // Programmed with pbLua - Thanks, Ralph!
0 // Scans assembled and processed with Meshlab,
0 // a tool developed with the support of the Epoch NOE
[0 !ENDOFHEADER]
0 // Body
Reply
Re: [LSC Request] End of header meta command
#9
Exactly. Those informations are good but not header relevant IMHO.

Whereas:
Code:
0 Tile  2 x  2 with Map Red/Blue/Green Border Pattern (Needs Work)
0 Name: 3068bpa0.dat
0 Author: Stan Isachenko [angmarec]
0 !LDRAW_ORG Unofficial_Part
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

0 BFC CERTIFY CCW
0 !KEYWORDS Adventurers

0 !HISTORY 2011-10-15 [MagFors] Corrected errors

0 // Needs work, many colinear vertices
this comment should go into the header data because it belongs to the "Needs Work" tag in the part description.
Reply
Re: [LSC Request] End of header meta command
#10
It sounds to me like we need a "0 !NEEDSWORK" meta-statement, then any "0 // ..." comment can be treated as not part of the header.

Some already consider the header to be bloated, so adding a mandatory "0 !ENDOFHEADER" would generate more bad vibes.
Chris (LDraw Parts Library Admin)
Reply
Re: [LSC Request] End of header meta command
#12
That would work too. Then all 0 // can be ignored.

Although I'd prefer 0 !NOTES (or similar) so we can include other header info. For example if a part is made by a script the settings used to generate it could be included.

And reading of the header can be terminated at the first 0 // or line type 1-5.

Tim
Reply
Re: [LSC Request] End of header meta command
#13
This would also mean that I/we only need to update the 139 official parts the "need work" rather than all official parts.
Chris (LDraw Parts Library Admin)
Reply
Re: [LSC Request] End of header meta command
#14
As far as I'm concerned I'd see it as voluntary. But I guess it would be nice to change the "Needs work" files to the new meta. But they 'need work' anyway so I don't think it's necessary. Your call.

Tim
Reply
Re: [LSC Request] End of header meta command
#15
If we go this way might I suggest using a more global meta with an eye on forwards compatibility.

Something like

Code:
0 !PTTAGS needsWork, placeHolder, someOtherFutureThing, etcEtcEtc

And also state when this meta is found it also indicates the end of the header. Just my 2cts.
Reply
Re: [LSC Request] End of header meta command
#16
I believe that the purpose of the 0 !NEEDSWORK was intended to be as a container for a description of what work is needed. So it would (presumably) be followed by a text description of the work. This wouldn't work with a single meta-command holding multiple flags. Also, "needs work" isn't related to the Part Tracker. It's an acknowledgement that the file has issues, but is still ok for inclusion in the official library once certified.
Reply
Re: [LSC Request] End of header meta command
#17
The meta statement sequence defined in the header spec is enforced for official parts (except maybe that !HELP lines can appear anywhere), and I'd still prefer !HISTORY to be the last header info as that is the part that grows.

My preference would be to add zero or more "0 !NEEDSWORK " meta statements immediately before the !HISTORY.

Every official part has at least one !HISTORY line, because the Parts Update mechanism generates one, so header parsers can then ignore everything after the last !HISTORY line.
Chris (LDraw Parts Library Admin)
Reply
Re: [LSC Request] End of header meta command
#20
Travis Cobbs Wrote:I believe that the purpose of the 0 !NEEDSWORK was intended to be as a container for a description of what work is needed. So it would (presumably) be followed by a text description of the work.

You could still follow with normal comment lines, why introduce yet another comment like meta?

I still think you could indicate end of header with a pattern (double empty line for example)
Reply
Re: [LSC Request] End of header meta command
#25
Agree. But not double lines as they are too easy to add by mistake. I've suggested "0 ////" below.

Tim
Reply
Re: [LSC Request] End of header meta command
#18
I find the introduction of a dedicated "end of header" meta complete overkill:

The header ends when the first line of type 1,2,3,4 or 5 is encountered.

To achieve this, I think that the introduction of a
0 !NEEDSWORK
meta would be a good idea.

All comments starting with
0 //
are intended for human-reading and should not carry semantic information for tools IMHO.
Reply
Re: [LSC Request] End of header meta command
#19
0 header
0 stuff
0 with no
0 defined ending

0 !TEXMAP etc etc.
1 a real part
0 !TEXMAP END

QED

I happen to agree that the header is too onerous. I have difficulty envisioning usecases for some of its contents. The !HISTORY lines in particular belong in CMS metadata; they do not belong in the source file itself. I don't see much value in adding a !NEEDSWORK because I don't see why that data needs to be machine-readable either.

But you cannot make the case that the header is currently machine-parseable. Nor can you, without an end-of-header designator, possibly write a future-proof header delineator.

I'm not going to get worked up about this; there are far more important issues. I'm just trying to set the record straight.

Allen
Reply
Re: [LSC Request] End of header meta command
#21
Allen Smith Wrote:The !HISTORY lines in particular belong in CMS metadata; they do not belong in the source file itself.

The textual content of the !HISTORY lines would belong in a Change Management System if the Parts Tracker used one (which it currently doesn't). However, the
Code:
0 !HISTORY YYYY-MM-DD [PTadmin] Official Update YYYY-RR
lines serve as a surrogate for a version number, so do have value to identify which version of an official part you have installed, and since they are programmatically generated are parse-able.
Chris (LDraw Parts Library Admin)
Reply
Re: [LSC Request] End of header meta command
#22
I'd like to revive this discussion with a very simple suggestion:

What if we terminate the header either at the first instance of a non-type-0 or at the first appearance of
Code:
0 ////

It's simple, fits existing standards, is easy to read algorithmically, and won't cause problems if it appears elsewhere.

Allen> A "needs work" tag is useful as machine-readable as it allows tools e.g. LDFind, to easily point out that a part could do with some touching up. Thus part authors can get a list of parts that they might improve.

Tim
Reply
Re: [LSC Request] End of header meta command
#23
The Parts Tracker seems to cope well with identifying the end of the header section as a non-type-0 line OR a 0 BFC INVERTNEXT.
Chris (LDraw Parts Library Admin)
Reply
Re: [LSC Request] End of header meta command
#24
Except it often gobbles up comments from within the part data. There are reasons to keep those internal comments away from end-users.

I'm certainly not proposing it as a compulsory solution, merely an optional one (and if DATHeader implements it then it will become a de facto standard).

Tim
Reply
Re: [LSC Request] End of header meta command
#43
Quote:Except it often gobbles up comments from within the part data.
...and even BFC invertnext if it's the first line in file
Reply
Re: [LSC Request] End of header meta command
#45
well, this can be easily repaired _without_ a new token.
it's a simple special case missing in the PT's logic.
Reply
Re: [LSC Request] End of header meta command
#26
I don't have a particular problem with an optional end-of-header token, but I don't feel that your proposed one is acceptable. We've already defined 0 // to be a comment which should never, under any circumstances, be treated as meta-information about the file. Your proposal goes against that.
Reply
Re: [LSC Request] End of header meta command
#28
I agree with Travis '0 //' should be protected.

Having reread the thread I'm ok with the original !ENDOFHEADER suggestion.

It should be optional though, when it's not present the header stops when the first 'mesh' related line is read (1..5, bfc, tex, etc).
Reply
Re: [LSC Request] End of header meta command
#27
Tim Gould Wrote:Allen> A "needs work" tag is useful as machine-readable as it allows tools e.g. LDFind, to easily point out that a part could do with some touching up. Thus part authors can get a list of parts that they might improve.

I could implement support for this in LDForge if it is ratified. I also would find the end-of-header meta command particularly useful. I think "////" sounds a little ambigous and unclear though. I'd prefer "0 !END_OF_HEADER" or something like that.
Reply
Re: [LSC Request] End of header meta command
#39
Let's drop "0 ////". I agree that it's a bad choice.

If we can settle on a meta I'll add it to LDMakeList too. It will make for a cleaner parts.xml file.

Tim
Reply
Re: [LSC Request] End of header meta command
#35
A couple of reasons in favor of the new meta command:

1. Without it software authors will need to write extra code which takes time and effort.
2. Also, software will become more complex and relatively more likely to have bugs.
3. Extra code will slow the software down, which can matter maybe when batch operating on a long list of files.
4. Having a command like this is less ambiguous for new part or model authors, meaning they will not get as confused.
Reply
Re: [LSC Request] End of header meta command
#29
no, no, no, I still strongly dislike the introduction of a new end-of-header token.

the existing defined semantics are enough to write some simple code to detect the end of the header: it is simply there where the first non-comment line comes, ie that is a line which is of type 1, 2, 3, 4 or 5, or a 0 BFC or 0 !TEXMAP or 0 !COLOUR

let me also question for what _purpose_ such a token would be useful:
1. what is so bad about LDFind if it indexes the whole file instead of just the first bunch of lines? don't you want to find _all_ occurrences of a word in a file?
2. if we're talking about using a revision control system for our parts like git, hg or Perforce, which I strongly suggest, then the _whole_ file will go into it, not just the header. That way our files would really get a lifecycle history of their full contents. We're talking about simple
fulltext files here still, which can easily be stored in tools like that, allowing easy diffing etc like for programming language source code files.

And yes, agreeing to the said things above: using anything that starts with 0 // must not be done under all circumstances,
because it breaks the rule that everything after 0 // is a totally free formatted,
no machine-readable-semantics-carrying human-readable comment.
the only degree of freedom we have here is choosing something that starts with 0 !...
Reply
Re: [LSC Request] End of header meta command
#30
Which of these things could you not do with an optional end of header token?
Reply
Re: [LSC Request] End of header meta command
#31
the question is the other way around: why introduce it when you can do without.
Reply
Re: [LSC Request] End of header meta command
#33
Well there are plenty of reasons given in this thread as to why it would be useful. So the onus is on you, I'm afraid.

So again I ask, why do you think we should not have it?
Reply
Re: [LSC Request] End of header meta command
#36
no, I've read all the posts. none of them carry an argument why you need a new token and cannot do without. they just talk about what could be done with some header data,
but they do not state why the existing stuff isn't enough.
I understand that you really want that new token, but each time you want to add something to such a standard, you need to prove why it is needed and existing stuff isn't enough.
it is not up to me to prove the opposite.
we need to minimize the syntax, avoid clutter and save time.
and the existing syntax suffices to detect the end of the header.
so that's 4 arguments you need to counter.
there's a 5th: if you make the tag optional, the tools supporting it anyway need a fallback implementation for files not carrying that token. and that fallback implementation would exactly read as I wrote above. Thus, this code anyway needs to be written. Thus, you do not need the tag. The code already suffices.
Reply
Re: [LSC Request] End of header meta command
#37
I assumed it's an presentation issue, you don't want to see the first part author comment block directly after the true header in e.g. a part description while using the part bin.

The meta would allow for nicer presentation of part info hints etc.
Reply
Re: [LSC Request] End of header meta command
#40
Roland Melkert Wrote:The meta would allow for nicer presentation of part info hints etc.

Exactly. It also makes it slightly easier to read by a person who can see that "oh! the header info ends here, the rest is part author chit chat".
Reply
Re: [LSC Request] End of header meta command
#38
> no, I've read all the posts. none of them carry an argument why you need a new token and cannot do without. they just talk about what could be done with some header data,

Not to you. To others they do.

> but they do not state why the existing stuff isn't enough.

Yes they do.

> I understand that you really want that new token, but each time you want to add something to such a standard, you need to prove why it is needed and existing stuff isn't enough.
it is not up to me to prove the opposite.

Not true. That's merely an argument that the conservative position is the right position. I take a progressive position that an improvement is worth doing unless it has negative consequences that outweight its benefits. This doesn't.

> we need to minimize the syntax, avoid clutter and save time.

I do agree with this to some degree. But the new meta would avoid a different sort of clutter (see point below).

> and the existing syntax suffices to detect the end of the header.

As has been pointed out several times, no they don't. They suffice to define an end of the header + lines of comment. Go look at the number of parts on the parts tracker with "0 // Some comment that has no place in the header" at the end of the header.

> there's a 5th: if you make the tag optional, the all tools anyway need a fallback implementation for files not carrying that token. and that fallback implementatioh would exactly read as I wrote above. Thus, this code anyway needs to be written. Thus, you do not need the tag. The code already suffices.

Ideally I'd like to see it made compulsory to ease coding (see Michael and Allen's posts) but I know that would never happen due to LDraw conservatism. Conversion of the library could be done using the existing rules.

This argument is basically "because you offered a compromise your proposal obviously has no merit".
Reply
Re: [LSC Request] End of header meta command
#46
Tim Wrote:This argument is basically "because you offered a compromise your proposal obviously has no merit".
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.
Reply
Re: [LSC Request] End of header meta command
#47
Quote: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.
That's a point. But it doesn't solve the startup comments issue...
Reply
Re: [LSC Request] End of header meta command
#48
Steffen Wrote:
Tim Wrote:This argument is basically "because you offered a compromise your proposal obviously has no merit".
Yes, exactly. You have to admit that this is a valid counterargument against the new syntax.

On the contrary. I think it is close to the worst counterargument possible. Especially since I never mentioned simplification of coding so it was a side show anyway from my perspective.
Reply
Re: [LSC Request] End of header meta command
#55
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
Reply
Re: [LSC Request] End of header meta command
#57
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
Reply
Re: [LSC Request] End of header meta command
#58
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).
Reply
Re: [LSC Request] End of header meta command
#59
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
Reply
Re: [LSC Request] End of header meta command
#60
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.
Chris (LDraw Parts Library Admin)
Reply
Re: [LSC Request] End of header meta command
#73
+1
Reply
Re: [LSC Request] End of header meta command
#86
This problem is designed with our current header and the forced comment for "needs work" explanations.

Code:
0 !HISTORY YYYY-MM-DD {RealName} Free text description of change

0 // Comments

If we agree on "needs work" comments needs to be mentioned before the !HISTORY lines all our problems are gone.
After the last !HISTORY line the header is finished.

Code:
0 // Needs work comments

0 !HISTORY YYYY-MM-DD {RealName} Free text description of change

0 // Comments
Reply
Re: [LSC Request] End of header meta command
#87
This is similar to what I suggested here:

http://forums.ldraw.org/showthread.php?t...33#pid8133

It would solve both the presentation and clutter problem.
Reply
Re: [LSC Request] End of header meta command
#41
I agree that the burden of proof for format extensions needs to be for why it is necessary.

But I think Roland has found one: the implicit algorithm can't tell the 'header' from in-part comments - they are different semantically but not syntactically; a new meta would make this visible in syntax for automated processing.

(If you are right and the header can be found strictly by existing algorithm, then formalizing that algorithm is valuable.)
Reply
Re: [LSC Request] End of header meta command
#42
Ben Supnik Wrote:But I think Roland has found one: the implicit algorithm can't tell the 'header' from in-part comments - they are different semantically but not syntactically; a new meta would make this visible in syntax for automated processing.

I hope people realise that example was given in my original proposal and was the main reason for the proposal...

Tim Gould Wrote:That way codes like LDMakeList of LDFind can know which comments are useful notes for the header (eg. in a needs work file) and which are just separators of the different part components (eg. 0 // Studs).

Tim
Reply
Re: [LSC Request] End of header meta command
#44
Ben Supnik Wrote:But I think Roland has found one: the implicit algorithm can't tell the 'header' from in-part comments - they are different semantically but not syntactically; a new meta would make this visible in syntax for automated processing.

Yes, that's true. That's the only thing that cannot be achieved by the current syntax.
However: let me counter this with the argument that this special case, where in-file comments
start right after the header, is very seldom. It only happens on exhaustively documented
parts, and my guess is that of all our currently official files this affects at most 10 or 20 or so files.
This doesn't convince me that the new token really is required. It does not really hurt if
these some extra comments are parsed as well, in these few special cases.
Especially since LDFind anyway indexes the whole file, which makes it more powerful.
We're talking here about a small beautification for a vanishing amount of files affected.
I cannot see the benefit. The small gain is outweighed by all the hassle of introducing the new language element.
This is my personal opinion.
In file format specification, minimalism is the way to go. It keeps the complexity of your format small.
If you too liberally add syntax elements, you end up with something as syntax-complex like perl.
You will not want to write an error-free parser for that...
Reply
Re: [LSC Request] End of header meta command
#49
The issue affects close to every part I ever submit because, like a well-behaved programmer, I comment as much as possible in my files. And after editing a moderately complex but uncommented part recently, I'm very glad I do comment.

So let me summarise the pros.

1) There is minimal hassle in introducing a simple meta like 0 !END_OF_HEADER.
2) Such a simple meta will be parsed correctly by old software, and thus its implementation would not be compulsory.
3) Part authors who use it could add more verbose comments in their files, making re-editing easier.
4) We thus avoid obsfucated LDraw and improve the quality of parts.

On the other hand, for cons we have

1) It is new.

Tim
Reply
Re: [LSC Request] End of header meta command
#50
I kind of believe we should try to keep things simple. I'd suggest make END_OF_HEADER mandatory if the body starts with a type-0-line, even if it were a BFC or TEXMAP statement. Thus the end of header is defined as either the first non-type-0 or END_OF_HEADER. No need for complex rules.

This is coming from someone who thinks allowing clock-wise winding for BFC and the ability to change a part's winding mid-file are stupid things, though. But I think we should keep things well-defined so I'm all for this meta-command as well as any NEEDS_WORK meta command.
Reply
Re: [LSC Request] End of header meta command
#52
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
Reply
Re: [LSC Request] End of header meta command
#54
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.
Reply
Re: [LSC Request] End of header meta command
#53
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.
Reply
Re: [LSC Request] End of header meta command
#51
A great example for a header with unwanted informations:
Link to 2515a on PT

/Max
Reply
Call for LSC Vote Re: [LSC Request] End of header meta command
#56
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
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#61
I'm not sure we can, like I asked here:

http://forums.ldraw.org/showthread.php?t...0#pid11760
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#62
I think that, whether or not we can, we should wait for the new election to complete, and let the new LSC take care of it. Tim, would you mind re-asking this after there is a new LSC?
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#64
That was my plan Smile And if people see fit to elect me I'll propose it myself.

Adding a reminder link (for myself) to Chris' post because he has spelled out all the options so clearly.

Tim
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#63
The fundemental mistake we made was to allow conventional "0 // ..." comments in the header to describe needs work actions:
Header spec Wrote:If the description includes "(Needs Work)", a comment must be added to the file immediately following the official header describing the work that needs to be done.

I'm not sure we have a single proposal to vote on. I see three options implicitly suggested:

1) Define a "needs work" meta-statement and update all such files.
The end-of header algorithm would then be the detection of a "0 // ..." comment or "0 BFC INVERTNEXT" or a non-type 0 line.
Algorithm clarity: medium, Implementation effort: low (154 official files).

2) Define an end-of-header meta statement and apply it to every part that has part content comments or a BFC statement immediately after the header.
The end-of header algorithm would then be the detection of that statement or a non-type 0 line.
Algorithm clarity: medium, Implementation effort: medium (probably > 154 official files).

3) Define an end-of-header meta statement and apply it to every part.
The end-of header algorithm would then be the detection of that statement. This would require the re-issue of the entire library in a Parts Update.
Algorithm clarity: high, Implementation effort: high (7930 part files).
Chris (LDraw Parts Library Admin)
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#65
Chris Dee Wrote:The fundemental mistake we made was to allow conventional "0 // ..." comments in the header to describe needs work actions

I think the fundamental mistake was not scoping the header to begin with.

Without a defined end-of-header marker, you must know either:
a) every type 0 meta command that could ever possibly be in the header
b) every type 0 meta command which will ever exist and never be in the header.

The problem is that neither can possibly be known. The header specification may sprout new header metas in the future, or the language may gain additional valid meta-commands which were not anticipated. Problem (b) has already happened, and I'm pretty sure case (a) has been bandied about, if not actually done.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#66
And if the solution comes to

3) Define an end-of-header meta statement and apply it to every part

and if you (all) will find this helpful I would offer to overtake the work of editing following your instructions for the whole library.
In this way you could focus on definining parts and perfecting the system (what I'm not able to do at the moment).

Constitutional principle :: From my point of view every "block" of informations of a specific type in a DAT file should start with an appropiate KEYWORD and end with END or ENDKEYWORD or ENDOFKEYWORD, independent of what will be packed inside, e.g.

0 !HEADER
:
0 !END

or

0 !HEADER
:
0 !ENDHEADER

or

0 !HEADER
:
0 !ENDOFHEADER

BTW Question: Is there a tool which checks a DAT file automatically for "correctness" ?
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#67
Arthur Sigg Wrote:BTW Question: Is there a tool which checks a DAT file automatically for "correctness" ?

Yes. Mike Heideman's (increasingly inaccurately named Wink ) DATHeader.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#68
It is named for the purpose of the first code Smile

My idea for DATHeader rised in the moment where a standarized header has been applied to the library.
"Who can remember all those things?" - me not.
So I started to write a tool that eliminates first the "BFC CERTIFY INVERTNEXT" and "ROTATION" lines that will be stored by MLCad. The design idea has been - open a file - save the file and it can be submitted to the pt.
More and more correction could be done over the time and where automatically corrected.

Starting from version 3 also the task for reviewing parts on the PT could be done with DATHeader. But there are still in the background the automatic correction that happens, so in some special tasks it is not easy today to implement only the check of a specific attribute in the file Smile
Therefore - please do not have a look at the code, it is horrorable - but it works Smile
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#69
Might I suggest a rename for the next major version to DATValidator, DATVerify, or something more apt?
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#70
From my point of view there will be no major update within the next years. Nearly all aspects are already covert.

Also I do not think that a rename will change anything. If someone is looking for such a tool he will find it - like now Smile
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#71
Thanks for explaining. Any specifications of the current performance of DATHeader and a summary of what's missing/planned ?

I never stick my nose in other people's code, except the programmer asks me. And not in case of "horrible" written code, except a tool is "horrible sophisticated" and well documented so I could expect a learning gradient for myself :-)
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#72
Arthur Sigg Wrote:Thanks for explaining. Any specifications of the current performance of DATHeader and a summary of what's missing/planned ?

Hmmm....
summary of what's missing/planned
Hmmm...
missing - nothing I hope
planned - currently nothing as exactly that is missing Smile

I guess with performance you are talking about the things that DATHeader cares about?
Below the list of flags that I work with and that are hopefully self explaining.
Code:
Public Enum LDraw_ErrorCode
        PovCodeFound = 1
        WRITEfound = 2
        BFCCERTIFYINVERTNEXTfound = 3
        ROTATIONfound = 4
        COLORfound = 5
        CommentsNotCorrect = 6
        NotOnlyLDconfigColors = 7
        MatrixAllZero = 8
        IdenticalVertices = 9
        ColinearVertices = 10
        BadVertexSequenze = 11
        ConcaveQuads = 12
        NonCoplanarQuads = 13
        ColorWrongForLinetype = 14
        LoopInReference = 15
        DoubleLinesfound = 16
        ColorForSticker = 17
        PartDescriptionLength = 18
        PartDescriptionLeadingSpaces = 19
        KeywordsLength = 20
        KeywordsCorrect = 21
        FiletitleMatchesFilename = 22
        AuthorRealname = 23
        AuthorUsername = 24
        BFCset = 25
        LicenseSet = 26
        PartTypeSet = 27
        BFC_CCW_at_Primitive = 28
        Keywords_at_Primitives = 29
        PartDescriptionWithTab = 30
        HelpLength = 31
        NewNotUsed = 32
        NeedWorkComment = 33
        Category = 34
        Category_at_Primitives = 35
        Primitive48FilenameStartwith48 = 36
        PrimitivePartDescriptionStartWithout_orTilde = 37
        PartFilenameStartwithout48orS = 38
        SubpartFilenameStartWithS = 39
        SubpartDescriptionStartWithTilde = 40
        SubpartDescriptionStartWithout_ = 41
        PartDescriptionStartWithout_ = 42
        ShortCutPartDescriptionStartWith_ = 43
        ShortCutFilenameContains_d_or_c = 44
        NameExtensionIsDAT = 45
        NoSpecialCharacterInDescription = 46
        LineEndWithCRLF = 47
        HistoryEntryAuthorBracket = 48
        PrimitiveIsScaled = 49
        PrimitiveIsScaledY = 50
        BFCINVERTNEXTfollowedbylinetype1 = 51
        CorrectRGBvalue = 52
        NoMoveToReferenceUsed = 53
        NoBFCCERTIFIEDCWorCCWfound = 54
        KeywordsUnique = 55
        MinifigAccessoryNotFound = 56
        FigureAccessoryNotFound = 57
        NotNeededInvertNextUsed = 58
        TJunctionDetected = 59
        SquareBracketsAroundUsername = 60
        AliasPartDescriptionStartWithSame = 61
        PhysicalColorMentionedInDescription = 62
        PhysicalColorPartOnlyLinetype1Used = 63
        PhysicalColorPartCorrectColorsUsed = 64
        AliasPartOnlyLinetype1Used = 65
        AliasPartOnlyOneLinetype1 = 66
        AliasPartOnlyColor16Used = 67
        AliasPartAliasMentionedInComments = 68
        AliasPartAliasNumberInComment = 69
        OriginNOTInBoundingBox = 70
        AmericanEnglishWords = 71
        EmptyLinesAtTheEnd = 72
    End Enum

And here the messages you will see if all is correct:
Code:
Public Sub InitialiseOKMessages()        
        ReDim FileResultOKMessages([Enum].GetValues(GetType(LDraw_ErrorCode)).Length)
        FileResultOKMessages(LDraw_ErrorCode.PovCodeFound) = "OK" & XMPD.MSVB.Tab & "Embedded POV Code not found."
        FileResultOKMessages(LDraw_ErrorCode.WRITEfound) = "OK" & vbTab & "'0 WRITE' not found."
        FileResultOKMessages(LDraw_ErrorCode.BFCCERTIFYINVERTNEXTfound) = "OK" & vbTab & "'0 BFC CERTIFY INVERTNEXT' not found."
        FileResultOKMessages(LDraw_ErrorCode.ROTATIONfound) = "OK" & vbTab & "'0 ROTATION' not found."
        FileResultOKMessages(LDraw_ErrorCode.COLORfound) = "OK" & vbTab & "'0 COLOR' not found."
        FileResultOKMessages(LDraw_ErrorCode.CommentsNotCorrect) = "OK" & vbTab & "Correct use of '0 //' for comments."
        FileResultOKMessages(LDraw_ErrorCode.NotOnlyLDconfigColors) = "OK" & vbTab & "All used colors in LDConfig.ldr."
        FileResultOKMessages(LDraw_ErrorCode.MatrixAllZero) = "OK" & vbTab & "Matrix all zero not found."
        FileResultOKMessages(LDraw_ErrorCode.IdenticalVertices) = "OK" & vbTab & "Identical vertices not found."
        FileResultOKMessages(LDraw_ErrorCode.ColinearVertices) = "OK" & vbTab & "Colinear vertices not found."
        FileResultOKMessages(LDraw_ErrorCode.BadVertexSequenze) = "OK" & vbTab & "Bad Vertex Sequence not found."
        FileResultOKMessages(LDraw_ErrorCode.ConcaveQuads) = "OK" & vbTab & "Concave quads not found."
        FileResultOKMessages(LDraw_ErrorCode.NonCoplanarQuads) = "OK" & vbTab & "Coplanarity."
        FileResultOKMessages(LDraw_ErrorCode.ColorWrongForLinetype) = "OK" & vbTab & "Correct color for linetype."
        FileResultOKMessages(LDraw_ErrorCode.LoopInReference) = "OK" & vbTab & "Loop in reference not found."
        FileResultOKMessages(LDraw_ErrorCode.DoubleLinesfound) = "OK" & vbTab & "Double lines not found."
        FileResultOKMessages(LDraw_ErrorCode.ColorForSticker) = "OK" & vbTab & "Correct colors for sticker used."
        FileResultOKMessages(LDraw_ErrorCode.PartDescriptionLength) = "OK" & vbTab & "Length of part description."
        FileResultOKMessages(LDraw_ErrorCode.PartDescriptionLeadingSpaces) = "OK" & vbTab & "Leading spaces in part description."
        FileResultOKMessages(LDraw_ErrorCode.KeywordsLength) = "OK" & vbTab & "Keywords entry length."
        FileResultOKMessages(LDraw_ErrorCode.KeywordsCorrect) = "OK" & vbTab & "None of the keyword are used in in part description."
        FileResultOKMessages(LDraw_ErrorCode.FiletitleMatchesFilename) = "OK" & vbTab & "Filename matches filetitle."
        FileResultOKMessages(LDraw_ErrorCode.AuthorRealname) = "OK" & vbTab & "Author real name is set."
        FileResultOKMessages(LDraw_ErrorCode.AuthorUsername) = "OK" & vbTab & "Author user name is set."
        FileResultOKMessages(LDraw_ErrorCode.BFCset) = "OK" & vbTab & "BFC is set."
        FileResultOKMessages(LDraw_ErrorCode.LicenseSet) = "OK" & vbTab & "License is set."
        FileResultOKMessages(LDraw_ErrorCode.PartTypeSet) = "OK" & vbTab & "Part type is set."
        FileResultOKMessages(LDraw_ErrorCode.BFC_CCW_at_Primitive) = "OK" & vbTab & "Winding for part type."
        FileResultOKMessages(LDraw_ErrorCode.Keywords_at_Primitives) = "OK" & vbTab & "Use of keyword for part type."
        FileResultOKMessages(LDraw_ErrorCode.PartDescriptionWithTab) = "OK" & vbTab & "Part description without Tab character."
        FileResultOKMessages(LDraw_ErrorCode.HelpLength) = "OK" & vbTab & "HELP entry length."
        FileResultOKMessages(LDraw_ErrorCode.NewNotUsed) = "OK" & vbTab & "Word 'new' or 'old' not used in part description."
        FileResultOKMessages(LDraw_ErrorCode.NeedWorkComment) = "OK" & vbTab & "Use of (Needs work)."
        FileResultOKMessages(LDraw_ErrorCode.Category) = "OK" & vbTab & "Entry for category."
        FileResultOKMessages(LDraw_ErrorCode.Category_at_Primitives) = "OK" & vbTab & "Category is not set."
        FileResultOKMessages(LDraw_ErrorCode.Primitive48FilenameStartwith48) = "OK" & vbTab & "High-res primitive has to start with '48\'."
        FileResultOKMessages(LDraw_ErrorCode.PrimitivePartDescriptionStartWithout_orTilde) = "OK" & vbTab & "Description for primitives should not start with '_' or '~' or '='."
        FileResultOKMessages(LDraw_ErrorCode.PartFilenameStartwithout48orS) = "OK" & vbTab & "Filename for parts, shortcuts and primitives should not start with '48\' or 's\' or '8\'."
        FileResultOKMessages(LDraw_ErrorCode.SubpartFilenameStartWithS) = "OK" & vbTab & "Filename for subparts has to start with 's\'."
        FileResultOKMessages(LDraw_ErrorCode.SubpartDescriptionStartWithTilde) = "OK" & vbTab & "Description for subparts has to start with '~'."
        FileResultOKMessages(LDraw_ErrorCode.SubpartDescriptionStartWithout_) = "OK" & vbTab & "Description for subparts should not start with '_' or '='."
        FileResultOKMessages(LDraw_ErrorCode.PartDescriptionStartWithout_) = "OK" & vbTab & "Description for parts should not start with '_' or '='."
        FileResultOKMessages(LDraw_ErrorCode.ShortCutPartDescriptionStartWith_) = "OK" & vbTab & "Description for shortcuts and/or physical_colour parts has to start with '_'."
        FileResultOKMessages(LDraw_ErrorCode.ShortCutFilenameContains_d_or_c) = "OK" & vbTab & "Filename for shortcuts contains usually a 'c' or 'd'."
        FileResultOKMessages(LDraw_ErrorCode.NameExtensionIsDAT) = "OK" & vbTab & "Extension is .dat"
        FileResultOKMessages(LDraw_ErrorCode.NoSpecialCharacterInDescription) = "OK" & vbTab & "No special characters in description found."
        FileResultOKMessages(LDraw_ErrorCode.LineEndWithCRLF) = "OK" & vbTab & "Lines ends with <CR><LF>."
        FileResultOKMessages(LDraw_ErrorCode.HistoryEntryAuthorBracket) = "OK" & vbTab & "Author !HISTORY entry has brackets."
        FileResultOKMessages(LDraw_ErrorCode.PrimitiveIsScaled) = "OK" & vbTab & "Not scalable primitives are not scaled."
        FileResultOKMessages(LDraw_ErrorCode.PrimitiveIsScaledY) = "OK" & vbTab & "Primitives are only scaled in Y direction."
        FileResultOKMessages(LDraw_ErrorCode.BFCINVERTNEXTfollowedbylinetype1) = "OK" & vbTab & "First line after BFC INVERTNEXT is linetype 1."
        FileResultOKMessages(LDraw_ErrorCode.CorrectRGBvalue) = "OK" & vbTab & "Correct RGB values used."
        FileResultOKMessages(LDraw_ErrorCode.NoMoveToReferenceUsed) = "OK" & vbTab & "No '~Moved to' file used."        
        FileResultOKMessages(LDraw_ErrorCode.NoBFCCERTIFIEDCWorCCWfound) = "OK" & vbTab & "No wrong BFC command found."
        FileResultOKMessages(LDraw_ErrorCode.KeywordsUnique) = "OK" & vbTab & "None of the keyword are used twice."
        FileResultOKMessages(LDraw_ErrorCode.MinifigAccessoryNotFound) = "OK" & vbTab & "No 'Minifig Accessory' found in part description."
        FileResultOKMessages(LDraw_ErrorCode.FigureAccessoryNotFound) = "OK" & vbTab & "No 'Figure Accessory' found in part description."
        FileResultOKMessages(LDraw_ErrorCode.NotNeededInvertNextUsed) = "OK" & vbTab & "Usage of 'INVERTNEXT' seems to be ok."
        FileResultOKMessages(LDraw_ErrorCode.SquareBracketsAroundUsername) = "OK" & vbTab & "Correct brackets around username used."
        FileResultOKMessages(LDraw_ErrorCode.AliasPartDescriptionStartWithSame) = "OK" & vbTab & "Description for alias parts should start with '='"
        FileResultOKMessages(LDraw_ErrorCode.PhysicalColorMentionedInDescription) = "OK" & vbTab & "Description for physical_color parts mention the used colors"
        FileResultOKMessages(LDraw_ErrorCode.PhysicalColorPartOnlyLinetype1Used) = "OK" & vbTab & "Only linetype 0 and 1 are used in this Physical_Colour part."
        FileResultOKMessages(LDraw_ErrorCode.PhysicalColorPartCorrectColorsUsed) = "OK" & vbTab & "No wrong color used for Physical_Colour part"
        FileResultOKMessages(LDraw_ErrorCode.AliasPartOnlyLinetype1Used) = "OK" & vbTab & "Only linetype 0 and 1 are used in this Alias part."
        FileResultOKMessages(LDraw_ErrorCode.AliasPartOnlyOneLinetype1) = "OK" & vbTab & "Only one (1) linetype 1 is used in this Alias part."
        FileResultOKMessages(LDraw_ErrorCode.AliasPartOnlyColor16Used) = "OK" & vbTab & "Only color 16 is used in this Alias part."
        FileResultOKMessages(LDraw_ErrorCode.AliasPartAliasMentionedInComments) = "OK" & vbTab & "Alias is mentioned in the comments."
        FileResultOKMessages(LDraw_ErrorCode.AliasPartAliasNumberInComment) = "OK" & vbTab & "Number in the Alias comment is correct."
        FileResultOKMessages(LDraw_ErrorCode.OriginNOTInBoundingBox) = "OK" & vbTab & "Origin is inside the Boundingbox."
        FileResultOKMessages(LDraw_ErrorCode.AmericanEnglishWords) = "OK" & vbTab & "Only Australian English words are used in the part description."
        FileResultOKMessages(LDraw_ErrorCode.EmptyLinesAtTheEnd) = "OK" & vbTab & "No more Empty lines at the end as necessary."
    End Sub

For some of the check standard values are used f.e. identical vertices etc. For more details I would need to have a close look into the code, so if you need some more information, please specify.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#74
you are basically re-inventing XML here.

ldraw originally is a linewise format (opposed to a correctly-parenthesed formal multiline programming language).

I dislike changing the linewise principle.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#75
I clearly favor solution 1).
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#76
I'm leaning toward option 1 too:

Quote:1) Define a "needs work" meta-statement and update all such files.
The end-of header algorithm would then be the detection of a "0 // ..." comment or "0 BFC INVERTNEXT" or a non-type 0 line.
Algorithm clarity: medium, Implementation effort: low (154 official files).

But it might be useful to also 'invent' a LDraw spec version meta so we can link the allowed meta list to the spec version. This way software can determine the needed list and has some kind of forwards compatibility for when a new meta gets added to the allowed list it doesn't now of yet.

Based on the version number it knows there might be additional meta's in the header and it could fall back to just including all unknown meta's or something.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#77
I'm in favor of a formal META for the reasons outlined by Allen. Unless someone come up with a compelling argument against his claims then I'm in his camp. Note that the reason "creates too much work" is null since these changes can be made on the back end by Chris without having to go through the PT.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#78
Well personally I like the idea to have strict info about all meta's allowed in a header. Software compliant with spec verison x then knows what it needs to read / manage from such a header.

Having the !EOH meta will solve the presentation part but allowing anything in the header makes it somewhat hard for software to support editing such a header.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#79
I do not see the presentation issue big enough
to justify the introduction of a new !EOH keyword.
It's just a small, cosmetic issue which can be easily solved by polishing the affected mentioned 154 parts
and/or extending the PT logic.
We should avoid keyword clutter.
Introducing new keywords can be become an addiction.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#80
... keyword clutter ! Never heard such a killer phrase ! That's the hammer on the nail ... unfortunately on the fingernail. This is definitively not the house I can live and work. The endless discussions in this "palaver hall" about the most simple things shows up the worst side of "democracy". I am a little bit disillusioned and somewhat disappointed, but I want to say "thank you" sincerely for all your help and kindness.

Good bye !
Arthur Sigg
-----
I know I am part of a story that starts long before I can remember and continues long beyond when anyone will remember me [Long Now: Danny Hillis, Desinger of the 10'000 Year Clock]
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#81
Whoah, Arthur, your reaction is by far too harsh.
I can only ask you to step back a little and reconsider.
Remember that we're discussing here a file standard used by thousands of users.
You must allow that an extensive discussion of such syntax extensions happens,
and also, that opposite opinions to yours are allowed to be said and heard the same way as yours is.
I am not an English native speaker, so when using the wording "keyword clutter" I did not intend a pun alongside with it.
I just wanted to express that we should be careful of minimizing the amount of specified keywords.
And on the introduction of each one, carefully consider.
There's no personal controversy going on here, especially not against you. All being said here is just exchanging
logical / technical arguments and counterarguments.
Take a deep breath and maybe a break of some days and then stay with us.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#82
It is still work that needs some manual intervention.

If it were possible to algorithmically determine where to insert the End-of-Header statement, it wouldn't actually need doing. Any files with "0 //" comments immediately following the !HISTORY will need to be reviewed to assess whether those are "Needs work" comments or "part content" comments, and the position of the End-of-Header statement adjusted.
Chris (LDraw Parts Library Admin)
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#83
Point taken. However, for ease of parsing we should either a) have a end of header meta or b) have everything in the header have a header only meta (ie have a meta that is only used in the header.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#84
Are you are suggesting a fourth option:

4) Define a "needs work" meta-statement update all (Needs Work) files and define an end-of-header meta statement and apply it to every part.
The end-of header algorithm would then be the detection of that statement. This would require the re-issue of the entire library in a Parts Update.
Algorithm clarity: high, Implementation effort: medium-high (programmatic plus manual update of probably > 154 official files).
Chris (LDraw Parts Library Admin)
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#85
No what I'm saying is either:

a) Have a EOH meta

-or-

b) Have every line in the header be under a meta that is illegal to be found outside of the header. This way once the first line without a header meta is encountered, that's the end of the header.

a is more futureproof that b but b requires less parts reissue. Personally, I don't see a problem with reissuing the entire library but some may object so I offer b as an alternative.
Reply
Re: Call for LSC Vote Re: [LSC Request] End of header meta command
#88
Orion Pobursky Wrote:a) Have a EOH meta
= option 3 here

Orion Pobursky Wrote:b) Have every line in the header be under a meta that is illegal to be found outside of the header. This way once the first line without a header meta is encountered, that's the end of the header.
I believe the only untagged header content is "Needs work" comments, so = option 1 here
Chris (LDraw Parts Library Admin)
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)