RISCOSPackageManagement

= RISC OS Package Discovery & Management =
This page was started after this discussion on Drobe. That discussion was primarily concerned with the idea of 'software discovery', and making sites like the Nutshells Software Directory either easier to maintain, or to supercede such sites with a more automagical system. ((anj))
I've summarized Phlamethrower's suggestion here:

• Each author and/or company has an XML file on their own site that describes their software. i.e. only one file in one place to keep up to date.
• These XML files would be cross-references so they could be indexed by a search engine spiderbot.
• Package management programs could be linked in to this system.

The language here implies a central service (single point of failure) as the search engine must understand the XML format. However, it is possible that each RISC OS user's machine could actually do the work of spidering and indexing the data via a custom application. Nevertheless, I feel it is still worth having a central registry, just to make sure people know how to get onto the spider's list, and as a mirror of the XML files for periods when the originating website is temporarily inaccessible. Also helps if the index of software becomes to large for everyone to have a mirror.
I also feel the system should ideally be linked up with (or rather, part of) the RiscPkg project, see:

• RiscPkg.org
• Drobe: RISC OS Package management
• Drobe: The Case for a RISC OS Package Manager

By this I mean that the XML files should describe things like dependencies and installation mechanism as well as a description of what it does and where to get it.
Well, this all sounds like it might be rather nice, but how the hell do we get started?
== Getting Started ==
In this discussion, quatermass asked the reasonable question: 'How does one write the XML?' Unfortunately, even this is jumping the gun somewhat. I've been involved in a few projects along similar lines to this, and the first step is always to define an agreed syntax (Schema) for the XML documents. XML is a handy standard, but almost entirely useless on its own. In order to exchange information, we must agree to use the same tag syntax to describe the same things.
Much progress has been made in developing frameworks for doing this. Currently, the simplest approach seems to be to use the Resource Description Framework (RDF, see here too). This standard, together with the widely adopted Dublin Core Metadata Initiative schema would provide a very strong basis for the package description. Using just these elements, we can do things like this:

 <?xml version="1.0"?>

 
    "http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd">

 
         xmlns:dc ="http://purl.org/dc/elements/1.1/">

 

   Dublin Core Metadata Initiative - Home Page

   The Dublin Core Metadata Initiative Web site.

   2001-01-16

   text/html

   en

   The Dublin Core Metadata Initiative

   

   L'Initiative de métadonnées du Dublin Core

   der Dublin-Core Metadata-Diskussionen

 

 

(taken from here).
The advantage of using this as a basis is that lots of folks and bits of software already understand this markup, and it will make sense to complete strangers (like a Googlebot) as well as to us.
If we adopt that, then the next issue is how we should extend this to create our a standard to describe software packages. Much to my suprise, I could not find anyone else who has already done this! The Linux community is certainly thinking along these lines (GNUpdate, Linux Packaging Specification, Linux Packages Metadata Mirroring Proposal), and I found some old w3 submissions from Microsoft too. Someone, somewhere, will standardize this stuff eventually, but maybe we'll get in first! The only solid examples I found were mirror.ac.uk's IDF and MDF extensions, and an RPM extension on Linux Packages Metadata Mirroring Proposal. Neither of these are quite right, but may provide some food for thought. This example of the IDF format is perhaps the closest: <?xml version="1.0" encoding="ISO-8859-1"?>

  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

  xmlns:dc="http://purl.org/dc/elements/1.0/"

  xmlns:idf="http://www.mirror.ac.uk/schemas/idf-metadata-01#">
  
    

      

        

        

      

    
    

      

	modified

1. -03-08T20:41:07

      

    
    redhat pub redhat redhat 6 2 i386 RedHat RPMS gnupg 1 0 1 1 i386 rpm

    562136

    application/octet-stream

    software

linux/redhat
all/linux
redhat
gnupg
GPL
GnuPG (GNU Privacy Guard) is a GNU utility for encrypting data and
creating digital signatures. GnuPG has advanced key management
capabilities and is compliant with the proposed OpenPGP Internet
standard described in RFC2440. Since GnuPG doesn't use any patented
algorithm, it is not compatible with any version of PGP2 (PGP2.x uses
only IDEA, patented worldwide, and RSA, which is patented in the US
until 9/20/00).

  

    1.0.1

  

  

    RPM

    Applications/Cryptography

  

  

    brief

    A GNU utility for secure communication and data storage.

  

To summarize, we have to decide what information we want to hold in our package definition, and agree on how to describe that information in terms of a simple extension to the RDF+DC decription format.
== Things to be included ==

• Name. Use .
• Description. Use .
• Type/Classification (perhaps we should use the Trove sofware map)
• Author|s. Use , , , etc. as required.
• Version. No existing DC element.
• Stable|Recent Release|Beta|Unstable. No existing DC element.
• Source/Binary. No existing DC element?
• Library/Application/...???. Perhaps use ? (Allows specification of MIME types, etc.)
• Compatibility. can apparently be used for this also.
• Known non-compatible conditions. again?
• Requirements. !
• Dependancies. No existing DC element (Although , may be partially appropriate)
• Installation. No existing DC element.
• How to uninstall it. No existing DC element.
• Languages (English, French, German, etc.). Use ?
• ScreenShots. No existing DC element.
• Icon. No existing DC element.
• Company Logo. No existing DC element.

????
We should work with the RiscPkg project to make sure everything that the package management system needs is present.
== Proposed RDF Structure ==
Use existing DC elements, as listed above. Need to investigate further.
???
== References ==

• Dublin Core Metadata Element Set, Version 1.1: Reference Description
• Resource Description Framework @w3.org

=== XML Tools ===

• An index of XML tools.
• Redland RDF Application Framework may port easily to RISC OS.