[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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@i...</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? xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|