The RDF/XML syntax is extremely verbose and confusing to those that don't understand RDF. It can be difficult to hand write and RDF APIs are not commonly available in programming platforms.

Possible Replacements

There are a few requirements that we need to consider for choosing a new format:

• Extensibility. The format must support adding new data without breaking backwards compatibility
• Hierarchical. The target application and localized data basically requires this.
• Support. The format should be well supported by editors and programming platforms alike, not to mention the Mozilla platform.

The fairly obvious candidates that meet all of these requirements are XML and JSON, both of which are far easier to write and read than RDF yet can easily contain the same data.

XML is likely to be the preferred choice. It is true that JSON is gaining ground and has good uses in web applications, however XML is far better supported in programming platforms as standard. Additionally XML makes it easy for us to create a schema describing valid documents. This would allow schema aware editors to tell users about potential problems with the manifest, even provide autocompleting in many cases.

Potential Form

Install Manifest

<?xml version="1.0" encoding="UTF-8"?>

<extension xmlns="http://www.mozilla.org/2008/em-manifest#"
           id="foo@bar.com" version="2.0">
  <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
    <versionRange minVersion="3.1" maxVersion="3.1.*"/>
  </targetApplication>

  <!-- UI metadata -->
  <name>Foobar</name>
  <description>An example extension</description>

  <updateURL>http://www.bar.com/update.xml</updateURL>

  <localization locales="en-CA,en-GB">
    <name>Foobar</name>
  </localization>

  <requires addon="bar@foo.com>
    <versionRange minVersion="1" maxVersion="5"/>
    <updateURL>http://www.foo.com/update.xml</updateURL>
  </requires>

</extension>

The document tag can change depending on the type of add-on (extension, theme, locale), no more obscure type numbers.

The versionRange adds the potential to support multiple version ranges per application/dependency easily.

I've added the updateURL into the requires as the potential way to deal with automatic resolution.

We could just ditch the namespace requirement.

Update Manifest

For the update manifest we could make extension author's lives much easier:

<?xml version="1.0" encoding="UTF-8"?>

<updates xmlns="http://www.mozilla.org/2008/em-manifest#">
  <extension id="foo@bar.com" version="3.0">
    <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
      <versionRange minVersion="3.1" maxVersion="3.1.*"/>
      <xpiURL hash="sha1:....">http://www.bar.com/foobar-3.0.xpi</xpiURL>
    </targetApplication>

    <requires addon="bar@foo.com>
      <versionRange minVersion="1" maxVersion="5"/>
      <updateURL>http://www.foo.com/update.xml</updateURL>
    </requires>
  </extension>
</updates>

Essentially we support much, if not all of the install.xml schema inside the update list. Authors can just copy their install.xml into the update.xml file.

Must think about how to sign