This is a tricky issue.
I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.
That way connectivity information does not have to be repeated in patterned versions of parts with identical geometry.
I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best. That's not to say that the conectivity library (or indeed the parts library) couldn't be distributed as a consolidated, optimised file, effectively a complied version of the library. So long as the tools understand how to deal with that.
I think the main question to ask to decide whether supplementary information (e.g. connectivity metadata) is stored within the part file is 'How often would a correction to the part geometry affect the connectivity metadata?'. If 'hardly ever', then I favour a separate file structure for connectivity info.
That way connectivity information does not have to be repeated in patterned versions of parts with identical geometry.
I know that there has been a lot of talk about the inefficiency of a 'one file = one part' structure of LDraw but from a library management perspective this still works best. That's not to say that the conectivity library (or indeed the parts library) couldn't be distributed as a consolidated, optimised file, effectively a complied version of the library. So long as the tools understand how to deal with that.
Chris (LDraw Parts Library Admin)