Opendocument web.xml file

A It may produce conforming OpenDocument extended packages, but it shall have a mode of operation where all OpenDocument packages that are created are conforming OpenDocument packages. B It shall be accompanied by a document that defines all implementation-defined values used by the OpenDocument package producer. It shall be accompanied by a document that defines all implementation-defined values used by the OpenDocument package producer.

An OpenDocument Package Consumer is a program that can parse and interpret OpenDocument packages, and that meets the following additional requirements:. A It shall be able to parse and interpret OpenDocument packages and OpenDocument extended packages, but it need not interpret the semantics of all elements, attributes and attribute values. B The XML parser used to parse the files listed in 2. OpenDocument defines a package file to store the XML content of a document as separate parts together with associated binary data as file entries in a single package file.

These file entries may be compressed to further reduce the storage taken by the package. OpenDocument Packages impose additional structure on the Zip file to accomplish the representation of OpenDocument Format documents. A document within a package may consist of a set of files creating a unit, for instance the set of files specified by OpenDocument Part 3. These files may be located in the root of the package, or within a directory.

If they are contained in the root of the package, they are called document. If they are located within a directory, the document they constitute is called a sub document.

A package may contain multiple sub documents, but only a single document can be contained in the root of the package. Unless otherwise stated, the term document refers to the document contained in the root of the package. This may include sub documents. This file is the OpenDocument package manifest. The manifest provides :.

The format of the manifest file is specified in chapter 4. This element specifies information regarding the document stored in the root of the package. This entry shall exist if the package contains a file "mimetype". See [RFC]. It shall not be compressed, and it shall not use an 'extra field' in its header.

If a Zip file contains a file at the beginning of the file that is uncompressed, and has no extra data in the header, then its file name and data can be found at fixed positions from the beginning of the package.

More specifically, one will find:. OpenDocument packages may be encrypted by encrypting some or all files within the package. The encryption process takes place in the following stages:. The information regarding the algorithms that were used to encrypt a file and required parameters are contained in the manifest. The manifest shall not be encrypted. The size of the encrypted file should replace the real size value in the file entry's central directory records, its local file header and the data descriptor, if any.

The original uncompressed, unencrypted size shall be contained in the manifest:size 4. Note: The encrypted form may be of greater size because of padding of plaintext, inclusion of additional information, and other characteristics of the encryption technique.

The three stages of the encryption process proceed as follows, using the legacy algorithms to illustrate each stage:. For each file, a byte salt is generated by a random generator. The salt is used together with the start key to derive a unique bit key for each file. The default iteration count for the algorithm is The files are encrypted: The random number generator is used to generate the 8-byte initialization vector for the algorithm.

The derived key is used together with the initialization vector to encrypt the file using the Blowfish algorithm in 8-bit cipher feedback 8-bit CFB mode see [Schneier]. Files within a package may have a digital signature applied.

The format of digital signature files is specified in chapter 5. A document or sub document that is stored in a package may contain any number of metadata files. Implementations that are consumers as well as producers should preserve all metadata files. This file enumerates metadata files and their relationships to other files in an OpenDocument package.

See chapter 6. In addition to metadata files, the "manifest. The "manifest. All references to a resource within the same package that occur within metadata file shall be represented by relative IRIs to the resource. This includes values of rdf:about attributes occurring within metadata files or metadata manifest files. Within the files contained in a package, relative IRIs as defined by [RFC] may be used to reference other files within the same package.

The file entry path is the file name of the file within the Zip file which contains the relative IRI, including its relative path. Otherwise the "relative-part" component of the relative IRI is copied into a relative IRI buffer and an empty file entry path buffer is created.

If the relative IRI buffer starts with the character sequence ". Continue with step 7. If the content of the relative IRI buffer is the character sequence ". Continue with step If the content of the relative IRI buffer is the character sequence ".. The query and fragment components of the relative IRI, if present, are appended to the relative IRI buffer, including the "? The ".. The content of the file entry buffer is inserted into the relative IRI buffer before any existing content.

The content of the relative IRI buffer is interpreted as a file or directory name within the package, that is, as the name of a file or directory including its relative path within the Zip file.

An empty buffer denotes the package root. Path segments in the relative IRI buffer that originally came from the relative IRI shall be interpreted according to IRI syntax rules, while segments that originally came from the file entry path must be interpreted according to Zip path name syntax rules.

Therefore, different rules regarding the resolution of relative IRIs may apply. Unless a document is encrypted, package producers should generate a preview image of the document that is contained in the package.

It should be a representation of the first page, first sheet, etc. For maximum re-usability of the preview images they shall be generated without any effects, surrounding frames, or borders. Note: Such effects might interfere with effects added to the preview images by the different file system explorers or may not be desired at all for certain use cases.

Preview images shall be saved in [PNG] format. Note: Current desktops display preview images within squares of up to pixel width and height, and 24 bit per pixel. While this specification does not define upper or lower limits for preview image sizes, producers should only use image sizes that are displayed with a reasonable quality if scaled to fit into x pixel square.

Encrypted documents are intended to be unreadable for unauthorized users and package producers shall not generate preview images for such documents. They may include a preview image that is independent of the contents of the document. Such preview images should not be encrypted.

An OpenDocument Package Producer that both encrypts files in the package and applies digital signatures to files in the package should either first encrypt per section 3. If the encryption of the files is done first, the digital signatures files shall not be encrypted. If the files in the package are encrypted after applying the digital signatures, the digital signature files shall be encrypted.

See also section 5. Note: It is current practice to first encrypt and then apply the digital signatures. See appendix A. This chapter describes the semantics of the elements and attributes defined by this schema. It may also specify the data required to decrypt a file. See 3. The Open XML Formats include many benefits — not only for developers and the solutions that they build, but also for individual people and organizations of all sizes:.

Compact files Files are automatically compressed and can be up to 75 percent smaller in some cases. The Open XML Format uses zip compression technology to store documents, offering potential cost savings as it reduces the disk space required to store files and decreases the bandwidth needed to send files via e-mail, over networks, and across the Internet.

When you open a file, it is automatically unzipped. When you save a file, it is automatically zipped again. You do not have to install any special zip utilities to open and close files in Office. Improved damaged-file recovery Files are structured in a modular fashion that keeps different data components in the file separate from each other.

This allows files to be opened even if a component within the file for example, a chart or table is damaged or corrupted. Support for advanced features Many of the advanced features of Microsoft require the document to be stored in the Open XML format. Better privacy and more control over personal information Documents can be shared confidentially, because personally identifiable information and business-sensitive information, such as author names, comments, tracked changes, and file paths can be easily identified and removed by using Document Inspector.

Better integration and interoperability of business data Using Open XML Formats as the data interoperability framework for the Office set of products means that documents, worksheets, presentations, and forms can be saved in an XML file format that is freely available for anyone to use and to license, royalty free. This means that customers can easily unlock information in existing systems and act upon it in familiar Office programs.

Information that is created within Office can be easily used by other business applications. Easier detection of documents that contain macros Files that are saved by using the default "x" suffix such as. Only files whose file name extension ends with an "m" such as. Before you decide to save the file in a binary format, read Can different versions of Office share the same files? By default, documents, worksheets, and presentations that you create in Office are saved in XML format with file name extensions that add an "x" or an "m" to the file name extensions that you are already familiar with.

In , Banco do Brasil began a process of migration to the open source software suite OpenOffice. As of February , this suite is found installed in more than 71, workstations, distributed among the branches and corporate offices. They have gathered a wide range of information to support their decision to adopt it and implement it across 5, desktop computers.

Robin Cover tracks the OpenOffice. Read more. Robin Cover's site supplies a provisional collection of references on XML file formats used in office applications. This Linux Journal article by Kamran Husain highlights the basic structure of ODF files, and some internals of the underlying XML files and shows how to use Python to read the contents to perform a simple search for keywords. The code also can be the basis for more advanced operations. In the spirit of openness, open-source software is used to read the ODF files, which in this case are Python and the OpenOffice.

It contains several chapters on ODF and accessibility tools, a business case checklist, and some hints on migrating to ODF. The book was sponsored by the Dutch Department of Economic Affairs. OpenDoc Society is currently seeking funding to translate the book into other languages.