Access Variable on Main Timeline from Package

Do you allow time before trying to target the main timeline?  Do you pass in a reference to the main timeline when you call in the package?

What do you mean by "call a package"? Note that its almost never a good idea for children to know about their parents, so you may want to back up and state the larger goal. That way we can give you a solution that's better practice than what you are asking for.

It's class, not package and it's not a good idea to mix timeline code and code in classes. One or the other - and preferably classes. 

I agree with dmennenoh that it's probably best not to mix the two, but let's start out assuming you do mix the two, and also the following

1. Your instance is called assessment5Q
2. You have a frame script on the same frame with the label you want to get.

Your frame script might look like:

assessment5Q.loadQuestions(currentFrameLabel);

Your Assessment5Q Class would have a method that looks like:

public function loadQuestions(label:String):void {
    //do your current load here
}

Now that your Class is set up to work from a framescript, it will work from a Document Class without modification. However, it sounds like your instance doesn't exist on frame 1 of the main timeline, so you need to make sure you don't try to reference your instance before it exists. So we're going to make use of a getter/setter pair, which will allow Flash to create your instance on the timeline per usual, but when the setter is triggered you can then do things with the new instance. Your main document code would include code something like this:

protected var _assessment5Q;
public function get assessment5Q():Assessment5Q {
     return _assessment5Q;
}
public function set assessment5Q(value:Assessment5Q):void {
     If (_assessment5Q != value) {
          _assessment5Q=value;
          If (_assessment5Q) {
               _assessment5Q.loadQuestions(currentFrameLabel);
          }
     }
}

Note that even this better way is not a way I'd recommend if you expect your project to take longer than a couple of days to develop or be maintained over more than a couple of weeks. It's not good practice to have a single Class that has the responsibility for both getting the data and displaying it. If you only have a single question format, you may be able to get away with having a Class that loads the questions and makes questions from it. Then you can pass the loaded questions into your View as above (instead of using a method that takes a string, you can use a method that takes an array of questions).

It just so happens that I build Assessments as the vast majority of the work I do, and I have it broken down where there is a Class that has some number of Classes inside it that know how to build individual question types. That Class gets XML handed to it (from a different Class that just handles loading XML) and then it figures out which child Class knows how to build each question type and hands a snippet of XML to the appropriate child. Once all the questions are created, a set of questions will be handed into a View that can show between 1 and 9 questions. It does this by having individual question views on stage that, again, know about displaying specific types of questions. I'm not saying that you need to go whole hog into creating such a scalable design as I have. I'm just suggesting that your product is more likely to stand the test of time if you break things into smaller pieces that then cooperate. That way if the bigger pieces aren't quite right, you can put the smaller pieces together in a different way.

Assuming that you add the closing tag and that everything between the opening and closing xml tags is in a variable called theXML, you'd find all "bonus" tags where the num attribute matches your bonusNum variable like this:

theXMLbonus(@num==bonusNum)