L.3.1.3 The Presentation Object
PresentationML also defines the content of the principal or start part for a PresentationML document. This content includes both structural and presentation-level data for the presentation.
Astute readers should quickly identify an apparent duplication of presentation-level data, as there is also a separate part which contains presentation-level data. That being said, there is actually no duplication. Rather, the differentiation of what presentation-level data goes into which part is based on two user scenarios: document signatures and document sanitization.
In a document signature scenario, assume a user digitally signs a presentation. There exist two kinds of data within the presentation package: data which changes the “content” of the presentation and data which is intended to configure an editor or the behavior of an editor. In the first case, any modification to data which changes the “content” of the presentation must invalidate the signature; in the second case, any modification to that data should not invalidate the signature.
A classic example of this scenario deals with Kinsoku information and the publish path in the HTML settings. If the user changes the Kinsoku information in a file, the file looks like (and potentially means) something different. This is in contrast to a user setting a new HTML publish path for their particular computer.
In a document sanitization scenario, users want to remove all non-necessary information from the file. A typical usage case would be posting a presentation to a company’s Internet site. In this case, you don’t want certain configuration information publicly available. The ideal manner of removal would be to remove an entire part from the presentation package as opposed to editing a part from a package.
Going back to our Kinsoku and HTML publish path example above, the Kinsoku information needs to remain with the file. The HTML publish path could give away internal information about web servers that could be used to facilitate an attack or, more likely, simply provide information about the author to the public (e.g., the path c:\documents and settings\shawnv\webpages strongly implies that “shawnv” published this document).
Going back to the original question—what presentation-level data goes in which part—we see that data that does not invalidate a digital signature or data that should be removed during a sanitization pass should be stored in the Presentation Properties part and other presentation-level data should be stored in the Presentation part.
In addition to structural and presentation-level data defined by this schema, there are also definitions for handling customer data and future extensibility. Again, both of these are addressed in additional
papers.