XSA Proposal - XML Software Autoupdate
From owner-xml-dev@ic.ac.uk Wed Aug 5 11:48:25 1998
Date: Wed, 05 Aug 1998 18:33:07 +0200
From: Lars Marius Garshol <larsga@ifi.uio.no>
Subject: XSA proposal
Below is attached a proposal for a specification for a system I'm
putting together and will use to keep my XML tools list up to date.
The system is currently using a restricted version of it and so far
it has worked well, apart from the fact that rather few developers
use it.
Making it a more "official" specification and enabling others to
use it as well will hopefully change this.
====== Start of proposal:
This is a proposal for XML Software Autoupdate, a system for
automatically keeping track of new releases of software products. It
is mainly intended for use by maintainers of software indices. The
default acronym for XML Software Autoupdate is XSA.
1. Introduction
1.1 Motivation and purpose
An XSA document is an XML document that describes the current status
of a software product marked up with the XSA DTD. It is intended that
software vendors and authors will maintain a single XSA document for
all their software, updating it every time a new version of a product
is released or some other information related to the product or the
vendor changes. This will allow all interested parties to poll the XSA
document and discover new releases and address changes automatically.
The polling model has been used since it requires less resources to
set up both for software vendors and XSA clients, and since is
expected that the number of interested parties for each software
product will be low. Should this turn out to not be the case the XSA
DTD could be used with only a minor modification in a notification
model.
2. Examples
2.1 Example document
Here is a sample XSA document:
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE software PUBLIC "-//LMG//DTD XSA 1.0//EN" "software.dtd">
<software>
<vendor>
<name>Lars Marius Garshol</name>
<email>larsga@ifi.uio.no</email>
<url>http://www.stud.ifi.uio.no/~larsga/</url>
</vendor>
<product id="xmlproc">
<name>xmlproc</name>
<version>0.50</version>
<last-release>19980718</last-release>
<info-url>http://www.stud.ifi.uio.no/~larsga/download/python/xml/xmlproc.htm
l</info-url>
<changes>
Version 0.50 conforms even more closely to the spec, some bugs
have been removed and there are now several ways to access DTD
information. Notation attributes are still not implemented.
</changes>
</product>
</software>
2.2 Example use
A maintainer of a software index might have as part of the entry for
the xmlproc parser the following information:
- the URL of the XSA document for this parser
- the ID of the parsers product element in that document
This could then be used by software to compare the information in the
XSA document with the information in the software index. If the
version numbers do not match the software can notify the maintainer,
allowing him or her to update the index.
3. The XSA DTD
3.1 The DTD itself
<!ELEMENT software (vendor, product+)>
This is the root element of the XSA document, and contains an element
with vendor information followed by elements describing that vendors
software products.
<!ELEMENT vendor (name,email,url?)>
The vendor element contains information about the vendor, in order
that the XSA software might keep track of changes in vendor names,
contact addresses and home page URLs.
<!ELEMENT name (#PCDATA)>
This element must contain the name of the software vendor or
author. WS treatment: normalize. (See section 3.2 for an explanation.)
<!ELEMENT email (#PCDATA)>
This element must contain an email address to be used for
correspondence regarding the software products listed in the XSA
document. WS treatment: remove.
<!ELEMENT url (#PCDATA)>
This element must contain the URL to a resource where information
about the software vendor or author can be found. WS treatment:
remove.
<!ELEMENT product (name,version,last-release,info-url?,
changes?)>
The product element contains information about a product, to be used
by XSA software to detect new releases of a product, name changes or
changes in the home page URL.
<!ATTLIST product id ID #REQUIRED>
The id attribute must contain an identifier for the product that must
be unique within the XSA document. This id should be used by XSA
clients to identify a particular product within an XSA document.
<!ELEMENT version (#PCDATA)>
This element must contain only the version identifier of the software
product. If the product release does not have a version identifier the
release date in ISO YYY format must be used instead. WS treatment:
normalize.
<!ELEMENT last-release (#PCDATA)>
This element should contain the date of the last release of the
software in ISO YYY format. WS treatment: remove.
<!ELEMENT info-url (#PCDATA)>
This element must contain the URL of a resource containing information
about the software product, preferably one suitable for linking to
the product. If no informational resources are available the URL must
refer to a resource containing the actual software instead. WS
treatment: remove.
<!ELEMENT changes (#PCDATA)>
This element must contain text describing the changes in the last
release of the software. WS treatment: normalize.
3.2 Whitespace treatment
Element PCDATA content can be processed in one of two ways before
being used by XSA software:
a) remove: this means that all whitespace characters as defined by
the S production of the XML 1.0 Recommendation must be
removed.
b) normalize: this means that all consecutive sequences of whitespace
characters as defined by the S production of the XML
1.0 Recommendation must be replaced by a single space
character. ( ) Whitespace before and after the
text must also be removed.
4. Further issues
4.1 Implementation
It is my intention to develop SDKs for working with XSA documents in
Java and Python, in order to lower the entry cost for XSA users.
Developments in other languages are of course also welcome.
4.2 Later extensions
It is likely that the XSA specification will be extended later to
allow XSA documents to be HTML or other XML DTDs than the XSA one.
This will probably be accomplished via SPAN elements in HTML and
architectural forms in XML.
It is also possible that an XSA push model may be added as an
alternative to the current polling model.
5. Open questions
- have an optional element in product for contact email? Defaults
to the email address in the vendor element if not present.
- should XSA have a namespace?
- what if WS results from character entity references? how to tell
and what to do?
- should the architecture use namespaces somehow?
- provide some means of XSA versioning and extensibility?
Date: Wed, 05 Aug 1998 13:42:17 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: XSA proposal
To: Lars Marius Garshol <larsga@ifi.uio.no>, xml-dev@ic.ac.uk
At 06:33 PM 8/5/98 +0200, Lars Marius Garshol wrote:
>This is a proposal for XML Software Autoupdate, a system for
>automatically keeping track of new releases of software products.
Isn't this what OSD, from MS & Marimba, is supposed to do? -Tim
Date: Fri, 07 Aug 1998 10:27:59 +0200
To: xml-dev@ic.ac.uk
From: Lars Marius Garshol <larsga@ifi.uio.no>
Subject: Re: XSA proposal
* Lars Marius Garshol
>
>This is a proposal for XML Software Autoupdate, a system for
>automatically keeping track of new releases of software products.
* Tim Bray
>
>Isn't this what OSD, from MS & Marimba, is supposed to do?
Yes, in a sense. However, XSA concerns itself with discovering
new versions and changed addresses, while OSD goes much further,
and omits some of the most useful parts of XSA.
Compare the example below from the OSD spec with the XSA sample
and I think you'll see what I mean. I looked at OSD before I
started this, but skipped it as it simply wasn't suitable for
my purposes.
<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>
--Lars M.
Date: Thu, 13 Aug 1998 07:11:52 -0400
From: Jeffrey Ricker <ricker@xmls.com>
Subject: Re: XSA proposal
Sender: owner-xml-dev@ic.ac.uk
Lars,
My first reaction was just like Tim's: this is OSD. But then I saw that it
was more of the e-commerce part rather than the mechanics of software
distribution. Am I right? If so, perhaps it should be a part of a larger
effort. Have you spoken to the RosettaNet project about your ideas?
Jeffrey Ricker
ricker@xmls.com
Date: Thu, 13 Aug 1998 14:21:57 +0200
To: xml-dev@ic.ac.uk
From: Lars Marius Garshol <larsga@ifi.uio.no>
Subject: Re: XSA proposal
* Jeffrey Ricker
>
>My first reaction was just like Tim's: this is OSD. But then I saw that it
>was more of the e-commerce part rather than the mechanics of software
>distribution. Am I right?
To tell you the truth my first reaction now was that I need to rewrite the
motivation part. :-)
XSA is supposed to solve a very simple problem: I and lots and lots of
other people maintain lists of software and we have a very difficult
time keeping them up to date. New versions are released that make our
descriptions obsolete, email addresses change, links die, product names
change etc etc
If developers could maintain XSA documents that listed these things anyone
who was interested could poll them for changes at intervals and discover
these things automatically. Today most software list maintainers simply
don't even try to keep their coverage up to date and instead rely on
developers to do it for them. The developers usually have their products
listed in too many places for this to be feasible, hence XSA.
What I've done besides the specification is to write a Java API and a
client that can be run from a cron job so that list maintainers (and
whoever else might be interested) can get email when something happens.
E-commerce never entered the picture, but that's not to say that an
expanded version might be useful in such a context as well. Or that XSA
might not make use of information published for e-commerce purposes.
>If so, perhaps it should be a part of a larger effort.
That would suit me well. For this to work people need to write actual
XSA documents, publish them and update them. This is the Achilles heel
of the project: if nobody does that XSA is dead. The more official this
looks the greater the chance that people will take it seriously to do
it. (Which is why I've now added OSD support. It's tested and it works,
as far as it goes.)
To alleviate this I've made two CGI scripts that give users a form to
fill out and return a validated XSA document ready for publishing.
That simplifies creation, but the real problem is to be taken seriously.
Also, the reason I've kept XSA as simple as possible (and omitting almost
everything in OSD) is to make the documents easy to create and modify.
For the purpose I had in mind I don't see any benefits to more
information, but that would make XSA harder to get started with.
>Have you spoken to the RosettaNet project about your ideas?
Never heard of it, I'm afraid. The stuff I dug up with AltaVista looks
like something that it might be possible to integrate with XSA (sort of
like I've now done with OSD), but I just didn't know about it before.
Do you have some URLs with details and perhaps some contact addresses?
--Lars M.
Date: Thu, 13 Aug 1998 11:58:44 -0400 (EDT)
From: Steven Champeon <schampeo@hesketh.com>
Subject: Re: XSA proposal
On Thu, 13 Aug 1998, Lars Marius Garshol wrote:
> XSA is supposed to solve a very simple problem: I and lots and lots of
> other people maintain lists of software and we have a very difficult
> time keeping them up to date. New versions are released that make our
> descriptions obsolete, email addresses change, links die, product names
> change etc etc
Yes.
> If developers could maintain XSA documents that listed these things anyone
> who was interested could poll them for changes at intervals and discover
> these things automatically. Today most software list maintainers simply
> don't even try to keep their coverage up to date and instead rely on
> developers to do it for them. The developers usually have their products
> listed in too many places for this to be feasible, hence XSA.
Linux developers (especially those using RedHat Package Manager, which -
side note to Tim - is one of the finest pieces of software for configuration
management I've ever worked with) have something like this already, though
not markup-language-based, called the Linux Software Map.
http://www.linux.org/apps/lsm.html
http://www.ExecPC.com/lsm/
Every piece of software produced for (or ported to) Linux is expected to
have a .lsm file included in its distribution. The format of the document
is simple, and described in this readme:
ftp://ftp.execpc.com/pub/lsm/LSM.README
I think this would make an excellent foundation for an XML application.
It might be useful to look at this as well as the IAFA format also
described the the above readme.
S
(my opinions only, not those of the WSP :) Heh.
Date: Thu, 13 Aug 1998 12:48:37 -0400
From: Daniel Veillard <Daniel.Veillard@w3.org>
Subject: Re: XSA proposal
Sender: owner-xml-dev@ic.ac.uk
Steven Champeon <schampeo@hesketh.com> wrote:
> Linux developers (especially those using RedHat Package Manager, which -
> side note to Tim - is one of the finest pieces of software for configuration
> management I've ever worked with) have something like this already, though
> not markup-language-based, called the Linux Software Map.
>
> http://www.linux.org/apps/lsm.html
> http://www.ExecPC.com/lsm/
I guess you should have a look at my RPM RDF database.
Principle: I mirror apprximately 15000 RPM packages from various distributions
I use a specific tool rpm2html [1] to extract all the metadata from the
packages, it dump them as a set of hyperlinked HTML [2] pages (the link
expressing verious dependencies between packages and distributions). The
same informations are encoded as an RDF database [3].
I also developped a client side tool rpmfind [4] which uses HTTP to
query the database and select the best packages for the current user setup
(by looking at the local installed software base too !).
This provide the user a list of packages to download to install a given
software (e.g. to install gimp you may need an exotic graphic library
not available on your system, rpmfind will solve that), then it also query
the database for mirrors and try to find the nearest one, and does the
FTP transfer for you if you want.
This software is based on (sorry !) my own XML and RDF code [5], currently
the database format is not valid XML but I will upgrade soon (probably within
a week) to something decent (with new namespace encoding). The FTP and
HTTP transfer are done using libWWW [6].
Example:
---------- /linux/RDF/redhat/5.1/i386/libc-5.3.12-27.i386.rdf ---------
<?XML version="1.0"?>
<?namespace href="http://www.rpm.org/" AS="RPM"?>
<?namespace href="http://www.w3.org/TR/WD-rdf-syntax#" AS="RDF"?>
<RDF:RDF>
<RDF:Description RDF:HREF="ftp://rufus.w3.org/linux/redhat/redhat-5.1/i386/RedHat/RPMS/libc-5.3.12-27.i386.rpm">
<RPM:Name>libc</RPM:Name>
<RPM:Version>5.3.12</RPM:Version>
<RPM:Release>27</RPM:Release>
<RPM:Arch>i386</RPM:Arch>
<RPM:Os>Linux</RPM:Os>
<RPM:Distribution>Manhattan </RPM:Distribution>
<RPM:Vendor>Red Hat Software</RPM:Vendor>
<RPM:Packager>Red Hat Software <bugs@redhat.com></RPM:Packager>
<RPM:Group>Libraries</RPM:Group>
<RPM:Summary>Compability libraries for old libc.so.5 applications</RPM:Summary>
<RPM:Description>Older Linux systems (including all Red Hat Linux releases between 2.0
and 4.2, inclusive) were based on libc 5. This package includes these
libraries and other libraries based on libc 5, allowing old applcications
to run on glibc (libc 6) based systems.</RPM:Description>
<RPM:Copyright>distributable</RPM:Copyright>
<RPM:Changelog>* Tue May 05 1998 Cristian Gafton <gafton@redhat.com>
- fixed postuninstall script
* Mon Apr 27 1998 Prospector System <bugs@redhat.com>
- translations modified for de, fr, tr
* Tue Dec 23 1997 Cristian Gafton <gafton@redhat.com>
- updated for the vsyslog() security-fixed libc
- uses a BuildRoot
* Mon Nov 10 1997 Erik Troan <ewt@redhat.com>
- updated Xpm lib to one built w/ dependency info
- added svgalib
* Tue Sep 23 1997 Erik Troan <ewt@redhat.com>
- added ncurses libraries
* Mon Sep 08 1997 Erik Troan <ewt@redhat.com>
- updated X libraries to 3.1.1
- added provides of libm.so.5
* Sun Aug 24 1997 Erik Troan <ewt@redhat.com>
- initial build as compatibility package
</RPM:Changelog>
<RPM:Sources>libc-5.3.12-27.src.rpm</RPM:Sources>
<RPM:SourcesFtp>ftp://ftp.redhat.com/pub/redhat/redhat-5.1/SRPMS</RPM:SourcesFtp>
<RPM:BuildDate>Tue May 5 23:54:21 1998</RPM:BuildDate>
<RPM:Date>894426861</RPM:Date>
<RPM:Size>5420357</RPM:Size>
<RPM:BuildHost>porky.redhat.com</RPM:BuildHost>
<RPM:Provides>
<RDF:Bag>
<RPM:Resource>libc</RPM:Resource>
<RPM:Resource>libc.so.5</RPM:Resource>
<RPM:Resource>libstdc++.so.27</RPM:Resource>
<RPM:Resource>libg++.so.27</RPM:Resource>
<RPM:Resource>libm.so.5</RPM:Resource>
</RDF:Bag>
</RPM:Provides>
<RPM:Requires>
<RDF:Bag>
<RPM:Resource>/sbin/ldconfig</RPM:Resource>
<RPM:Resource>grep</RPM:Resource>
<RPM:Resource>fileutils</RPM:Resource>
<RPM:Resource>/lib/ld-linux.so.1</RPM:Resource>
<RPM:Resource>/bin/sh</RPM:Resource>
</RDF:Bag>
</RPM:Requires>
<RPM:Files>/usr/i486-linux-libc5/lib
/usr/i486-linux-libc5/lib/libICE.so.6.0
/usr/i486-linux-libc5/lib/libICE.so.6.3
/usr/i486-linux-libc5/lib/libPEX5.so.6.0
/usr/i486-linux-libc5/lib/libSM.so.6.0
/usr/i486-linux-libc5/lib/libX11.so.6.1
/usr/i486-linux-libc5/lib/libXIE.so.6.0
/usr/i486-linux-libc5/lib/libXaw.so.6.1
/usr/i486-linux-libc5/lib/libXaw3d.so.6.1
/usr/i486-linux-libc5/lib/libXext.so.6.1
/usr/i486-linux-libc5/lib/libXext.so.6.3
/usr/i486-linux-libc5/lib/libXi.so.6.0
/usr/i486-linux-libc5/lib/libXmu.so.6.0
/usr/i486-linux-libc5/lib/libXpm.so.4.9
/usr/i486-linux-libc5/lib/libXt.so.6.0
/usr/i486-linux-libc5/lib/libXtst.so.6.1
/usr/i486-linux-libc5/lib/libc.so.5.3.12
/usr/i486-linux-libc5/lib/libform.so.1.9.9e
/usr/i486-linux-libc5/lib/libg++.so.27.1.4
/usr/i486-linux-libc5/lib/libm.so.5.0.6
/usr/i486-linux-libc5/lib/libmenu.so.1.9.9e
/usr/i486-linux-libc5/lib/libncurses.so.1.9.9e
/usr/i486-linux-libc5/lib/libpanel.so.1.9.9e
/usr/i486-linux-libc5/lib/libstdc++.so.27.1.4
/usr/i486-linux-libc5/lib/libtermcap.so.2.0.8
/usr/i486-linux-libc5/lib/libvga.so.1.2.11
/usr/i486-linux-libc5/lib/libvgagl.so.1.2.11
</RPM:Files>
</RDF:Description>
</RDF:RDF>
-----------------------------------------------------------------------
You can grab linux binaries and source at:
ftp://rufus.w3.org/pub/rpmfind/
There is now quite a few mirror for the HTML pages and 2 mirrors for
the RDF database,
Daniel
[1] http://rufus.w3.org/linux/rpm2html
[2] http://rufus.w3.org/linux/RPM/
[3] http://rufus.w3.org/linux/RDF/
[4] http://rufus.w3.org/linux/rpm2html/rpmfind.html
[5] http://dev.w3.org/cgi-bin/cvsweb [XML,rpmfind,rpm2html]
[6] http://www.w3.org/Library/
--
Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks :
Tel : +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html,
Fax : +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe,
http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)