[quote pid='25848' dateline='1502137415']
> I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like
[/quote]
I think that that is not needed, because LSYNTH files either can be
- parts
or
- subparts
but nothing 3rd.
Their only "problem" is that they have to be "misplaced" into the PARTS folder currently,
as long as nobody extends LSYNTH with the tiny modification to also look in the PARTS\S folder.
Thus, I don't feel that a new header syntax is missing, because the existing header syntax already correctly allows to express what a file _is_.
What is not possible today is to put the file into its proper folder,
but that's not the fault of the file.
Introducing the new header element masks this problem away by attributing the file with something new,
but that for me only falsifies the otherwise already correct contents of the file.
What must be corrected is their location, not contents IMHO.
> I am proposing extending the header spec to allow a new quaifier to allow these files to be identified with a line like
[/quote]
I think that that is not needed, because LSYNTH files either can be
- parts
or
- subparts
but nothing 3rd.
Their only "problem" is that they have to be "misplaced" into the PARTS folder currently,
as long as nobody extends LSYNTH with the tiny modification to also look in the PARTS\S folder.
Thus, I don't feel that a new header syntax is missing, because the existing header syntax already correctly allows to express what a file _is_.
What is not possible today is to put the file into its proper folder,
but that's not the fault of the file.
Introducing the new header element masks this problem away by attributing the file with something new,
but that for me only falsifies the otherwise already correct contents of the file.
What must be corrected is their location, not contents IMHO.