Specification for the Open Software Description (OSD) Format

August 11, 1997

Authors (alphabetically)

Arthur van Hoff, Marimba, Inc.
Hadi Partovi, Microsoft Corporation
Tom Thai, Microsoft Corporation

Contents

Abstract
1. Introduction
2. Representation of OSD: XML
3. Specific Uses and Benefits of OSD
4. Examples of the OSD Vocabulary for Describing Software Dependencies
5. "Pull" or "Push" Models of Software Distribution on the Web
   5.1. HTML 4.0 and software "pull"
   5.2. The Channel Definition Format (CDF) and software "push"
6. OSD Extensibility Using XML Namespaces
7. The OSD Reference
   7.1. Major elements
   7.2. Minor elements
   7.3. Element definitions
8. Conclusion
9. References
Appendix A -- The Complete OSD DTD
Appendix B -- Enumeration of Legal Attribute Values

Abstract

This document provides an initial proposal for the Open Software Description (OSD) format. OSD, an application of the Extensible Markup Language (XML), is a vocabulary used for describing software packages and their dependencies for heterogeneous clients. We expect OSD to be useful in automated software distribution environments.

UpBack to contents

1. Introduction

The primary medium for software distribution used to be the magnetic floppy disk. Companies and individuals alike used "floppies" to transfer software and data from one computer to another. Presently, compact discs (CDs) have surpassed floppy disks as the distribution medium of choice because of their digital nature and capacity to store a greater amount of data.

Without a doubt, we are witnessing computers move away from the stand-alone, or "unconnected," model of operation, and migrating into a networked environment. As a result, the network itself becomes a more powerful medium for software distribution. The physical medium is the network cable itself, a fixed cost associated with the establishment of the network. Therefore, distributing and installing software over an existing network bypasses the cost overhead of producing CDs or floppy disks.

In addition, using the network as the distribution medium profoundly reduces the software's total cost of ownership -- something that cannot be achieved by CDs or floppies even if these two media cost nothing to manufacture. Software distribution via CDs and floppies obey the "pull" paradigm, where every action is user-initiated. Distribution over the network has the ability to apply a "push" paradigm, thereby providing the following three features:

  1. Hands-free install -- user does not need to manually install software.
  2. Easy and timely upgrade from a designated location -- the burden of software upgrades is placed on the software itself.
  3. Cross platform -- reduces complexity for the user by providing cross-platform software, or the correct version of platform-specific software. The user is guaranteed to receive working software in both cases.

This specification shows how to describe software packages originating from a server that serves a set of arbitrarily heterogeneous clients. OSD can be used to deploy:

OSD has the ability to describe software dependencies in the form of a directed graph. This is a useful and necessary feature because for software engineered in a modular fashion, we should handle the situation where one component requires the presence of another to operate.

This document is not intended to serve as an OSD tutorial; it merely provides a complete description of the OSD vocabulary and its syntactic expression based on the Extensible Markup Language (XML).

UpBack to contents

2. Representation of OSD: XML

The goal of the OSD format is to provide an XML-based vocabulary for describing software packages and their inter-dependencies, whether it is user-initiated ("pulled") or automatic ("pushed"). XML (Extensible Markup Language) provides a general method of representing structured data in the form of lexical trees. Using this data model, markup tags in the OSD vocabulary are represented as elements of a tree. The three basic relationships between elements are parent-of, child-of, and sibling-of. Distant relationships can be formed from recursive applications of the three basic ones.

For the purposes of real-life applications, the OSD tree is expressed in a plain text file, although the XML language can also be compressed ("compiled") to more compact representations.

UpBack to contents

3. Specific Uses and Benefits of OSD

There are a number of ways in which the OSD vocabulary can be used.

UpBack to contents

4. Examples of the OSD Vocabulary for Describing Software Dependencies

By specifying software dependencies as a directed graph, OSD has the flexibility to freely modularize software package descriptions. Directed means that OSD distinguishes which software package requires another, and which software package is required by another. Graph means that each software package is represented as a node, where any node can have zero or more incident arcs. The distribution name is the node label. The dependency specifies the directed arc.

The OSD syntax allows describing one or more dependencies that a software component has on other components. In addition, OSD provides a syntactic means for describing different conditional dependencies depending on the OS platform, CPU architecture, and language of the machine interpreting the OSD vocabulary.

The following example shows how OSD expresses dependencies. Each OSD file specifies one level of dependency information. By allowing one OSD to reference other OSD files, an arbitrarily large dependency graph can be formed.

    <SOFTPKG NAME="com.foobar.www.Solitaire" VERSION="1,0,0,0">
        <TITLE>Solitaire</TITLE>
        <ABSTRACT>Solitaire by FooBar Corporation</ABSTRACT>
        <LICENSE HREF="http://www.foobar.com/solitaire/license.html" />
    
        <!--FooBar Solitaire is implemented in native code for Win32, 
            Java code for other platforms -->
        <IMPLEMENTATION>
            <OS VALUE="WinNT"><OSVERSION VALUE="4,0,0,0"/></OS>
            <OS VALUE="Win95"/>
            <PROCESSOR VALUE="x86" />
            <LANGUAGE VALUE="en" />
            <CODEBASE HREF="http://www.foobar.org/solitaire.cab" />
        </IMPLEMENTATION>
    
        <IMPLEMENTATION>
            <IMPLTYPE VALUE="Java" />
            <CODEBASE HREF="http://www.foobar.org/solitaire.jar" />
            
            <!-- The Java implementation needs the DeckOfCards object -->
            <DEPENDENCY>
                <CODEBASE HREF="http://www.foobar.org/cards.osd" />
            </DEPENDENCY>
        </IMPLEMENTATION>
    </SOFTPKG>

A client must read the OSD file and determine the relevant implementations and dependencies, given the client's local configuration. To fully discover the correct graph of dependencies, the client may have to download additional OSD files. For example, in the above situation, the "cards.osd" refers to an additional OSD file that specifies further second-level dependencies. The client can use the resulting graph to determine which implementations are relevant and need to be downloaded to complete the installation of the package.

UpBack to contents

5. "Pull" or "Push" Models of Software Distribution on the Web

5.1. HTML 4.0 and software "pull"

"Pull"-based software distribution on the Web involves user action to discover, download, and update software. While OSD makes it easy to automate the download and installation of required software components, this model still requires Web users to browse to an HTML page that initiates the software installation process. The <OBJECT> tag from the HTML 4.0 specification (working draft) or the <APPLET> tag from the HTML 3.2 specification (W3C recommendation) is used to "advertise" the presence of new software on the Web. Upon detecting an OBJECT or APPLET tag pointing at an OSD resource, an OSD-aware user agent can automatically download and update the necessary software components (with the informed consent of the user, of course).

The syntax for referencing an OSD package in HTML is:

    <OBJECT CLASSID="clsid:9DBAFCCF-592F-101B-85CE-00608CEC297B" 
            VERSION="1,0,0,0" 
            CODEBASE="http://www.acme.com/test.osd" 
            HEIGHT=100 WIDTH=200 >

    </OBJECT>

or

    <APPLET code=foo.class id=testid width=320 height=240>
            <PARAM NAME=useslibrary VALUE="test">
            <PARAM NAME=useslibraryversion VALUE="0,0,0,1">
            <PARAM NAME=useslibrarycodebase VALUE="test.osd">
    </APPLET>

Details on the OBJECT tag in HTML 4.0 can be found at http://www.w3.org/TR/WD-html40/html40.txt Non-MS link. Details on the APPLET tag in HTML 3.2 can be found at http://www.w3.org/TR/REC-html32.html Non-MS link.

Note: The CODEBASE attribute in <OBJECT> and the useslibrarycodebase parameter in <APPLET> may point directly to an OSD file, or they can alternatively point to an archive package (e.g., CAB, JAR) that contains the OSD file as well as additional software files.

UpBack to contents

5.2. The Channel Definition Format (CDF) and software "push"

The Channel Definition Format (CDF -- also based on XML) provides a meta-data vocabulary for describing inter-relationships between HTML pages and other Web resources. CDF-aware clients may use "smart-pull" techniques to automatically download Web content, and CDF-aware servers may implement "true-push" mechanisms for automatic distribution of content from client to server. CDF thus provides a language for content "push," providing the ideal leverage point for enabling software "push," or automatic distribution of software. In order for CDF to activate software "push," a CDF file needs to include references to OSD-based software packages. This can be accomplished by including the <SOFTPKG> tag in CDF.

    <CHANNEL HREF="http://www.acme.com.intropage.htm">
        <SELF="http://www.acme.com/software.cdf" />
        <TITLE>A Software Distribution Channel</TITLE>
        
        <SOFTPKG
                HREF="http://www.acme.com/aboutsoftware.htm"
                NAME="{D27CDB6E-AE6D-11CF-96B8-444553540000}"
                VERSION="1,0,0,0">

            <IMPLEMENTATION>
                <OS VALUE="WinNT"><OSVERSION VALUE="4,0,0,0"/></OS>
                <OS VALUE="Win95"/>
                <PROCESSOR VALUE="x86" />
                <CODEBASE HREF="http://www.acme.com/test.cab" />
            </IMPLEMENTATION>
        </SOFTPKG>
    </CHANNEL>

UpBack to contents

6. OSD Extensibility Using XML Namespaces

The XML "Namespaces" mechanism makes it possible to extend any XML document using vocabulary belonging to different "schemas". Conventional XML documents use names (e.g., element names, attribute names, etc.) whose meaning is associated directly with the document's document type. The Layman-Bray proposal for XML Namespaces allows anybody to combine vocabulary from different DTDs in a single XML document without name conflicts.

Within OSD, it may be desirable to define additional XML elements or attributes to provide additional functionality for vendor-specific needs. For example, InstallCorp, a particular vendor of software distribution tools, may want to extend the dependency graph described in the OSD vocabulary to include installation instructions for specific files or components referred to by the vocabulary. The XML Namespaces mechanism can be used for exactly this purpose. 

    <?xml::namespace href=http://www.installcorp.com/foo.dtd as="installcorp"?>

    <SOFTPKG
            installcorp::specialattr="foo"
            NAME="{D27CDB6E-AE6D-11CF-96B8-444553540000}"
            VERSION="1,0,0,0">

        <IMPLEMENTATION>
            <PROCESSOR VALUE="x86" />
            <CODEBASE HREF="http://www.acme.com/test.cab" />
        </IMPLEMENTATION>

        <installcorp::special_tag1>
            <special_tag2>
                This text is interpreted only by InstallCorp.
                <special tag3/>
            </special_tag2>
        </installcorp::special_Tag>
    </SOFTPKG>

For more information on XML Namespaces, see http://www.w3.org/Member/9708/WD-rdf-syntax-970801.html Non-MS link (please note that this link requires a W3C password).

UpBack to contents

7. The OSD Reference

7.1. Major elements

This section gives a short description of the major elements in the OSD vocabulary. The relation between major elements and the minor elements that they contain, as well as the attributes of all elements, are given in section 7.3. Element definitions.

Note: The grouping of major and minor elements exists in this document for organizational and descriptive purposes only. Such a distinction is not necessary, and therefore, does not exist in OSD.

SOFTPKG

Defines a general software package. The root of the OSD lexical tree is always SOFTPKG.

IMPLEMENTATION

A child of SOFTPKG, used to describe an implementation of a software package.

DEPENDENCY

A child element of SOFTPKG or IMPLEMENTATION used to indicate a dependency between software distributions, or components thereof.

UpBack to contents

7.2. Minor elements

TITLE

A child of SOFTPKG; the title, or "friendly name," of the software package.

ABSTRACT

A child of SOFTPKG; a short description summarizing the nature and purpose of a software distribution.

LICENSE

A child of SOFTPKG; indicates the location where a license agreement or copyright notice can be retrieved.

CODEBASE

A child of IMPLEMENTATION; this indicates a location (usually on the network) where an archive of the software distribution exists. If more than one CODEBASE is specified, then any one of the multiple URLs is valid, and any one of them may be used at random (for load-balancing reasons). Omission of the CODEBASE element is generally an error, and is treated in the same manner as if CODEBASE were present with an invalid HREF.

OS

A child of IMPLEMENTATION; indicates the required operating system.

Note that there may be zero or more instances of this element, specifying the set of particular operating systems that this implementation runs on. If no OS is specified, then the particular implementation runs on all operating systems.

OSVERSION

A child of OS; indicates the required operating system version.

Note that there may be zero or more instances of this element, specifying the operating system versions that a software implementation runs on. If no OSVERSION is specified for a particular OS, then the implementation is assumed to run on all versions of that operating system.

PROCESSOR

A child of IMPLEMENTATION; indicates the required processor (CPU).

Note that there may be zero or more instances of this element, specifying the set of particular processor architectures that an implementation runs on. If no PROCESSOR is specified, then the particular implementation runs on all processors.

LANGUAGE

A child of IMPLEMENTATION, indicates the required natural language in the software's user interface.

Note that there may be zero or more instances of this element, specifying the set of particular languages that an implementation requires. If no LANGUAGE is specified, then the particular implementation runs on all languages.

VM

A child of IMPLEMENTATION; indicates the required virtual machine.

MEMSIZE

A child of IMPLEMENTATION; indicates the required amount of run-time memory.

DISKSIZE

A child of IMPLEMENTATION; indicates the required amount of disk space.

IMPLTYPE

A child of IMPLEMENTATION; indicates the type of the implementation.

UpBack to contents

7.3. Element definitions

Element ABSTRACT
Content <string>
Child of SOFTPKG

 

Element CODEBASE
Attributes SIZE=<max-KB> -- the maximum allowable size for the software archive file. "Kilobytes" is the unit of measure. If SIZE is exceeded, then the software will not be downloaded.

HREF=<URL> -- points to the archive to be downloaded.

FILENAME=<string> -- specifies a file contained within the same archive as the OSD. If the OSD is used as a stand-alone file, then this attribute is ignored.
Child of IMPLEMENTATION

 

Element DEPENDENCY
Attributes ACTION= (Assert | Install) -- Assert means: Ignore this SOFTPKG entirely if the dependency is not already present on the client's machine. Install means: If the dependency is not already present on the client's machine, go get it, then install it, so that the SOFTPKG has all the pieces it needs.
Child of SOFTPKG, IMPLEMENTATION
Parent of SOFTPKG

 

Element DISKSIZE
Attributes VALUE=<KB-number> -- approximate minimum number of bytes of disk space required by this implementation. "Kilobytes" is the unit of measure.
Child of IMPLEMENTATION

 

Element IMPLEMENTATION
Attributes None Supported
Child of SOFTPKG
Parent of CODEBASE, DEPENDENCY, DISKSIZE, IMPLTYPE, LANGUAGE, OS, PROCESSOR, VM

 

Element IMPLTYPE
Attribute VALUE=<string> -- the type of the implementation.
Child of IMPLEMENTATION

 

Element LANGUAGE
Attributes VALUE= <string> -- uses language codes as specified in ISO 639.
Child of IMPLEMENTATION

 

Element LICENSE
Attributes HREF
Child of SOFTPKG

 

Element MEMSIZE
Attributes VALUE = <KB-number> approximate minimum number of bytes of memory required by this implementation during execution. "Kilobytes" is the unit of measure.
Child of IMPLEMENTATION

 

Element OS
Attributes VALUE= <string> -- see Appendix B for a list of possible values.
Child of IMPLEMENTATION

 

Element OSVERSION
Attributes VALUE=<string>
Child of OS

 

Element PROCESSOR
Attributes VALUE= <string> -- see Appendix B for a list of possible values.
Child of IMPLEMENTATION

 

Element SOFTPKG
Attributes HREF -- indicates the Web page associated with a software distribution. Optional.

NAME=<string> -- the name of the distribution. For a given SOFTPKG, this attribute should be a unique identifier. The client can use NAME to distinguish one SOFTPKG from all others. A software package's "friendly-name" is specified by using the TITLE element.

VERSION=<string>
Child of DEPENDENCY
Parent of ABSTRACT, CODEBASE, IMPLEMENTATION, DEPENDENCY, TITLE

 

Element TITLE
Content <string>
Child of SOFTPKG

 

Element VM
Attributes VALUE
Child of IMPLEMENTATION

UpBack to contents

8. Conclusion

Today, we are already starting to see the network surpass the compact disc as the software distribution medium of choice. However, with no existing standard for describing software packages, each application has no choice but to invent its own proprietary format for doing so.

This proposal lays the foundation for how applications can use OSD as a cross-platform language to describe software packages of both cross-platform software and platform native code. Clearly, OSD provides value by eliminating the need to "reinvent the wheel" and by increasing the potential for interoperability between applications.

UpBack to contents

9. References

1. Ellerman, Castedo. "Channel Definition Format", Microsoft Corp.: Redmond, WA. (http://www.w3.org/TR/NOTE-CDFsubmit.html Non-MS link)

2. Bray, Tim. "Extensible Markup Language (XML): Part I. Syntax", Texuality: Vancouver, BC, Canada. (http://www.w3.org/pub/WWW/TR/WD-xml-lang.html Non-MS link)

UpBack to contents

Appendix A -- The Complete OSD DTD

<!ELEMENT ABSTRACT (#PCDATA)>

<!ELEMENT CODEBASE EMPTY>
<!ATTLIST CODEBASE FILENAME CDATA #IMPLIED>
<!ATTLIST CODEBASE HREF CDATA #REQUIRED>
<!ATTLIST CODEBASE SIZE CDATA #IMPLIED>

<!ELEMENT DEPENDENCY (CODEBASE|SOFTPKG)* > 
<!ATTLIST DEPENDENCY ACTION (Assert|Install) "Assert">

<!ELEMENT DISKSIZE EMPTY>
<!ATTLIST DISKSIZE VALUE CDATA #REQUIRED>

<!ELEMENT IMPLEMENTATION (CODEBASE | DEPENDENCY | DISKSIZE | 
  IMPLTYPE | LANGUAGE | OS | PROCESSOR | VM)*>

<!ELEMENT IMPLTYPE EMPTY>
<!ATTLIST IMPLTYPE VALUE CDATA #REQUIRED>

<!ELEMENT LANGUAGE EMPTY>
<!ATTLIST LANGUAGE VALUE CDATA #REQUIRED>

<!ELEMENT LICENSE EMPTY>
<!ATTLIST LICENSE HREF CDATA #REQUIRED>

<!ELEMENT MEMSIZE EMPTY>
<!ATTLIST MEMSIZE VALUE CDATA #REQUIRED>

<!ELEMENT OS (OSVERSION)*> 
<!ATTLIST OS VALUE CDATA #REQUIRED>

<!ELEMENT OSVERSION EMPTY> 
<!ATTLIST OSVERSION VALUE CDATA #REQUIRED>

<!ELEMENT PROCESSOR EMPTY> 
<!ATTLIST PROCESSOR VALUE CDATA #REQUIRED>

<!ELEMENT SOFTPKG (ABSTRACT | IMPLEMENTATION | DEPENDENCY | LICENSE | 
  TITLE)*>
<!ATTLIST SOFTPKG NAME CDATA #REQUIRED>
<!ATTLIST SOFTPKG VERSION CDATA #IMPLIED>

<!ELEMENT TITLE (#PCDATA) >

<!ELEMENT VM EMPTY>
<!ATTLIST VM VALUE CDATA #REQUIRED>

UpBack to contents

Appendix B -- Enumeration of Legal Attribute Values

OS values:

CPU values:

UpBack to contents