This is the mail archive of the davenport@berkshire.net mailing list for the Davenport project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

DAVENPORT: How to describe provided and required features of a software package?


I'd like to know if there's a good way to describe provided and required
features of a software package. I tried to find the content model for
such a description in DocBook with no luck, and then went on to look for
a content model elsewhere. Whew! I've listed some of the resources that
I've found below (there's also a lot of inspiration to be had from
Configuration Management resources).

Did I miss something, or is there an element set for 'software packages'
in DocBook?

I don't need to be able to describe the interdependencies of the
components in a weapons system; I just want to be able to describe the
setup of the production environment that we use. I want to able to
identify each component as a 'package': how to get it, what features and
services does it provide, what features and services from other packages
does it rely on, how to install and set it up, etc. etc.

Should I start by examining 'rpm2html', 'OSD', or maybe try finding an
aerospace or telecom DTD with an element set for 'packages'?

W3C Resource Description Framework (RDF) is a foundation for processing
metadata; it provides interoperability between applications that
exchange machine-understandable information on the Web. RDF emphasizes
facilities to enable automated processing of Web resources. RDF is
similar to STEP in that it is an enabling framework or infrastructure,
i.e., it doesn't by itself solve any problems.
http://www.w3.org/RDF/
http://www.w3.org/TR/REC-rdf-syntax/
'rpm2html' is an example of how RDF can be applied to a problem domain
that looks like what I'm looking for. rpm2html automatically generate
Web pages describing a set of RPM packages; rpm2html now support RDF
encoding and decoding of RPM metadata. The long term goal is to provide
metadata information for RPM packages on a large scale and use them to
automate searching, installing and upgrade linux packages.
http://rpmfind.net/linux/rpmfind/

Product Data Markup Language (PDML), an XML format for exchange of STEP
product model data. Useful if you need to manufacture or maintain B-52s;
but eventually, there will be some 'spillover' to less demanding parts
of the industry.
http://www.pdit.com/pdml/
A very nice white paper at http://www.pdit.com/pdml/whitepap.pdf
A very nice presentation at
http://www.pdit.com/pdml/meetings/IPR4/PDMLOver.ppt

RPM uses 'spec' files to describe software packages, installation,
dependencies etc. RPM and similar systems seem to be quite mature. A
package can provide a 'virtual package' that other packages can specify
as required.
http://www.rpm.org/maximum-rpm.tar.gz, Chapter 13, Inside the Spec File

Open Software Description (OSD), a Microsoft/Marimba proposal to W3C, an
XML format for description of software components, their versions, their
underlying structure, and their relationships to other components. Each
package is identified by a unique name. A package description can refer
to the locations of required packages.  
http://www.w3.org/TR/NOTE-OSD.html
http://msdn.microsoft.com/workshop/management/osd/osdfaq.asp
Used e.g. by ActiveState to automate installation of Perl modules:
http://www.activestate.com/activeperl/docs/lib/site/XML/PPD.html

Jini is Sun's idea about how devices can create impromptu connection and
exchange of services and data on a network. The technology is specified
in terms of Java (wouldn't you guess). I can't find a general data model
for description of provided/required features; all the papers and specs
that I've seen focus on the protocol and the general arcitecture. 
http://www.jini.org/whatisjini.html
http://www.sun.com/jini/specs/

Kind regards
Peter Ring


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]