xml-dev - XSA proposal

[Lars Marius Garshol <larsga@ifi.uio.no>]

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. (&#x20;) 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?



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)