[Archive copy mirrored from: http://www.w3.org/TR/NOTE-OSD.html, August 15, 1997]
NOTE-OSD
This document is a NOTE made available by the W3 Consortium for discussion only. This indicates no endorsement of its content, nor that the Consortium has, is, or will be allocating any resources to the issues addressed by the NOTE.
This document is a joint submission to W3C from Marimba Incorporated and Microsoft Corporation. Please see Acknowledged Submissions to W3C regarding its disposition.
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.
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 standalone, 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 whichsomething 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:
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].
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.
There are a number of ways in which the OSD vocabulary can be used.
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 install of the package.
"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 whichpage 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. Details on the APPLET tag in HTML 3.2 can be found at http://www.w3.org/TR/REC-html32.html.
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.
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>
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
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 3.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
IMPLEMENTATION
DEPENDENCY
TITLE
ABSTRACT
LICENSE
CODEBASE
OS
OSVERSION
PROCESSOR
LANGUAGE
VM
MEMSIZE
DISKSIZE
IMPLTYPE
| 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 standalone 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 is 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 |
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.
1. Ellerman, Castedo. "Channel Definition Format", Microsoft Corp.: Remond, WA. http://www.w3.org/TR/NOTE-CDFsubmit.html
2. Bray, Tim. "Extensible Markup Language (XML): Part I. Syntax", Texuality: Vancouver, BC, Canada. http://www.w3.org/pub/WWW/TR/WD-sml-lang.html
<!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 LICENCE EMPTY> <!ATTLIST LICENCE 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>