Does anyone have advice to offer about .pln files and sets of .pln files?

Somebody has asked me find out how they can run queries to mark up sections of a test plan. I experimented for the first time with defining testplan attributes and using symbols in testplans. While going over those chapters in the manual I also built up some simple networks of .pln files using include statements. Everything seems to do exactly what it says on the tin ,which is encouraging.

However ,the new problem is to decide which mix of testplan attributes ,symbols and other techniques is going to be most useful to help achieve a goal that has not quite made the transition from a pipedream to the back of a beermat yet. This has all the early signs of heading for slow death by commitee in a string of unproductive meetings. Which is why I am asking for advice from anyone who has actual experience of large testplans so that I can make recommendations based on something more solid that applied guesswork.

In particular I would like some advice on what not to do and some of the pitfalls that might trap novices.

For instance ,is there any advantage to trying to keep the depth of a given testplan tree uniform across all its branches? Is there any advantage to putting a limit of branches from a given node? Is there any advantage to putting restrictions on the nodes where assignments are made to attributes and symbols? For instance ,should all assignments be made at the leaves or the root and not the nodes in between?

Another concern I have is that although the small networks of .pln files I have connected with the include statements so far work well ,this may not be the case as the bulk of the .pln files and their number increases. Is there a scalability problem lurking ahead for large .pln files?

Finally ,if anybody who has been down this road ahead of me is happy to let me steal any ideas they have about standards of large testplan design and how to map those ideas into a structure in .pln files then I could really use that help. There is bound to be at least one meeting ,and I would like to be able to walk in and say "This is the way we are going to write Silk testplans because <insert name> has used this method and refined it over a number of large projects and it works" in the hope that it will also be the last meeting on the subject.

I am sorry that I cannot be more specific about the nature of all these different testplans ,but at the moment I do not have any more information than that there are 'a lot' of test automation scripts 'out there' to be structured in a plan. The only way from here is up.