SCORM 1.2 Suspend Data--Seems Wonky to My Pea Brain

Hello again, Gerry and Steve.

Thanks for being so persistent, guys.  We appreciate you keeping us in check, and I apologize if I missed the crux of this thread.  I may have had tunnel vision on the question, "Does Storyline's suspend_data really need to be so large, or do we have a potential bug here?"  It seems that there is more to to your concerns than that, and here is what I am hearing:

1. You'd like to have better documentation on precisely which slide objects and properties impact the size of our suspend_data.  For example, is it worthwhile to reduce the number of slide layers, or is it not?
2. You'd like to see us restructure our suspend_data to prioritize the most important data elements at the front of the string.  For example, we might decide that scores are more important than interaction results, so scores should therefore go first.

I'm happy to try and advocate for these requests, but I think I need Steve to clarify one thing first...  Given that we compress our suspend_data, is it really helpful to prioritize the data within?  Here's my train of thought, which may or may not be accurate:

• If I want to email a large text file to a friend, I might decide to zip it first.
• Let's say that the zip file is truncated in transit for some reason.
• Upon receipt, I wouldn't expect my friend to be able to read the portion of the file that didn't get truncated.  I'd expect my friend to not be able to unzip the text file at all.

Is this an accurate analogy, or is there something unique about the way suspend_data is compressed that would allow the intact portion of a truncated, compressed string to be readable?

Thanks again, guys!