XSA: XML Software Autoupdate Lars Marius Garshol - 19990121 Version 1.0 This is the specification of 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 indexes, and not for automatic updating of installed software like OSD. However, XSA supports OSD. The default acronym for XML Software Autoupdate is XSA. 1. Introduction 1.1 Motivation and purpose An XSA document is an XML document[XML] that describes the current status of a list of software products 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. A mapping from OSD[OSD] to XSA has been defined, to enable XSA clients to poll OSD documents as well as XSA documents. XSA documents contain more relevant information than OSD documents, but some software vendors may only offer OSD documents. A reverse mapping has not been defined, since XSA documents do not contain sufficient information to be useful for OSD purposes. 1.2 Acknowledgements James Tauber, Robin Cover and Tim Bray provided useful input on the design of XSA. 2. Examples 2.1 Example document Here is a sample XSA document: Lars Marius Garshol larsga@ifi.uio.no http://www.stud.ifi.uio.no/~larsga/ xmlproc 0.50 19980718 http://www.stud.ifi.uio.no/~larsga/download/python/xml/xmlproc.html 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. 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 This is the root element of the XSA document, and contains an element with vendor information followed by elements describing that vendors software products. This element holds the version number of the XSA specification that the XSA document conforms to. It is declared as #FIXED since no other values than "1.0" are allowed in XSA version 1.0. 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. This element must contain the name of the software vendor or author. WS treatment: normalize. (See section 3.2 for an explanation.) This element must contain an email address to be used for correspondence regarding the software products listed in the XSA document. WS treatment: remove. This element must contain the URL[RFC1738] to a resource where information about the software vendor or author can be found. WS treatment: remove. 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. 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. For XSA clients to be able to identify the product across name and product changes, the id must remain constant. 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 8601[ISO 8601] format must be used instead. WS treatment: normalize. This element should contain the date of the last release of the software in the ISO 8601 format YYYYMMDD. WS treatment: remove. 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. This element must contain text describing the changes in the last release of the software. WS treatment: none. 3.2 Whitespace treatment Element PCDATA content can be processed in one of three 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[XML] 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[XML] must be replaced by a single space character. ( ) Whitespace before and after the text must also be removed. c) none: whitespace must be passed to the application untouched. 3.2 Public text The correct formal public identifier to use when referring to the XSA DTD is: -//LM Garshol//DTD XML Software Autoupdate 1.0//EN//XML 4. Further issues 4.1 Mapping from OSD to XSA Since OSD documents contain information useful for XSA systems, a mapping from OSD to XSA is given here. XSA software is not required to implement this mapping. OSD documents are to be mapped to XSA documents by interpreting the the OSD 'VERSION' attribute on the 'SOFTPKG' element as the XSA 'version' element and the OSD 'TITLE' element type as the XSA 'name' element type. In other words, an OSD document only contains information about a single product. Mapped documents do not conform to the XSA DTD, since too much information is left out. However, it is still possible for XSA software to perform basic update notification tasks. 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 the XSA DTD will eventually get its own namespace. The XSA DTD may also be extended to provide for extensibility. This will most likely happen by adding elements with content model ANY whose contents are to be ignored by standard XSA processors and where extra information can be placed. It is also possible that an XSA push model may be added as an alternative to the current polling model. These (and any other possible) extensions will very likely happen only if this is requested or if the need for extensions becomes sufficiently obvious. Backward compatibility will be retained as far as possible. 5. References [XML] http://www.w3.org/TR/REC-xml [OSD] http://www.microsoft.com/standards/osd/default.asp [RFC1738] RFC 1738 - Uniform Resource Locators (URL), Berners-Lee, Masinter, McCahill [ISO8601] ISO 8601:1988 - Date/Time Representations