What's wrong with PAD files

There are quite a lot of things that are just simply wrong in the IT industry nowadays, I have already discussed the case of the Google Adwords, let’s move to the subject of PAD files.

PAD stands for Portable Application Description, it’s an XML format designed by the shareware industry to facilitate the submission of software products to software directories. The idea is pretty simple and pretty nice. As a software manufacturer, you create a PAD file for each one of your products; then you publish this PAD file directly on your website. For example, when Lokad did release its first open source product named Lokad Sales Forecasting for ASP.Net, I have created and submitted a PAD file for this application.

Submitting through cut-and-paste

Before PAD, you were just manually submitting your product description to every software directory of the web. Now with PAD, you’re still submitting your product description to every single software directory on the web; but the submit operation is now (usually) restricted to a single operation: cut-and-pasting the URL of your PAD file. The support for PAD among the shareware/freeware distributor industry is really impressive. I would guess that over 95% of the freeware / shareware industry now supports PAD files.

But the only thing really impressive about PAD is its absolute lack of design.

When the XML design makes no sense

As a software producer, you don’t need to manually generate your PAD file, you got a free editor (www.padgen.org) for that. Yet, I don’t think I have ever seen an XML schema that is so massively adopted while being so poorly designed.

They are so many issues with PAD that it’s actually hard to even summarize the topic. Following a quasi-random order, the main PAD issues would be

• You need to specify the size of your software in bytes, kilo-bytes AND mega-bytes (File_Size_Byte, File_Size_K AND File_Size_MB). Don’t you think that this information is somehow redundant?

• The requirement description is restricted to OS version. What about required 3rd party software like DirectX or .Net?

• Open source (or source availability) is not part of the fields; furthermore it is not really possible to use PAD to describe open source software.

• Software components / library cannot be described. It does not really “fit” the PAD template.

• The software category field make no sense; a tag based system (think swik.net) would have been some much simpler AND so much more efficient.

• No (X)HTML support for your description fields. Your software description ends up plain text. As a result, big lump of texts (like the 2000 characters description) are almost totally unreadable.

• No consistence in XML tags naming

  • some tags are UPPER_CASED.
  • some tags are Camel_Cased.
  • some tags are explicit Program_System_Requirements.
  • some tags are abbreviated Char_Desc_45.

• The localization makes no sense (localizing a software ~ translating the software + adapting to the regional settings)

  • only the Description tag can be localized.
  • not possible to localize the other fields like contact or support emails, like the screenshot.
  • no encoding specified upfront in the XML file.

• The company address fields makes no sense for non-US locations (State_Province only apply to USA/Canada).

• Why hard-coding the cost in US Dollars (Program_Cost_Dollars)? There are a lot of currency out-there. Then why not being able to support a price list? (list of currency/value).

• The Download URL section is just moronic. You can specify up to 4 download URLs (why 4?) and the each URL gets its own special tag with no naming consistency

  • Primary_Download_URL / Secondary_Download_URL / Additional_Download_1 / Additional_Download_2
  • why not simply providing a URL lists?

• The screenshot section is restricted to a single image URL. Why not a list?

• No extensive mechanism for the affiliate programs (because the list of affiliate programs is hard-coded).

Note that all those suggestions would have made PAD easier to document, to produce and to consume.

Then some high-level criticisms could also be made

• no mechanism to link to other PAD files (especially useful to support software versions).
• no persistent mechanism using Global Identifiers (especially useful to detect replicated PADs).
• no mechanism to retrieve the PAD files by simply crawling the web (think XML feed links in HTML pages).

Summary: PAD has been designed by junior high kids (probably)

Based on the previous elements, we could say that the PAD authors had no clue about

• XML design: tag naming is random, data structures like lists are ignored.
• Web design text readability is not a concern, screenshots are unimportant.
• The world outside of the USA: utterly naive attempt to support internationalization.
• Software industry: operating systems are the only components worth to be mentioned.

Still, I think that a Portable Application Description is based on a good idea, but it would really need to be re-designed from scratch.

---

Reader Comments (3)

I use PAD files all of the time in conjunction with Shareware Tracker www.accusolve.biz/strack.html to submit shareware for clients. I agree there are a few problems with PAD files but in general, it is a great tool. I have defended a few of your claims below.

1. The reason for having to specify your program size in bytes, kb and Mb is to cater for each different site. One site may want kb and one might want mb. If you are using free PADGen, it will automatically fill all of those file size fields for you. All you have to do is click on the file and it works it all out.
2. You can include things like DirectX or .NET in the System Requirements field. No reason why you can’t.
3. Most shareware sites do not support HTML in their descriptions. You can include carriage returns though to make it readable.
4. State_Province applies to many other places other than the US. I am in Australia and we have states too.
5. Some sites will only pull the primary download URL, others will pull additional download URLs. You need to include each of these separately. The additional download URLs are for mirror URLs which can be useful if the primary download URL is not working for whatever reason. (the naming of the fields is a bit silly I agree).
6. Same for the screenshot URL. Most sites only allow one screenshot URL. I have been submitting shareware since before PAD ( www.softwaresubmit.com ) and I am a big PAD fan because it makes my job so much easier. Having said that, there are a few things which could be improved, but I guess it is a case of not being able to cater for everybody. (Please note PADGen 3 has just been released see www.asp-shareware.org/pad/ ). March 12, 2007 | Eve Sheridan

---

Thanks to challenge my criticisms. Yes, I am also a fan of the PAD concept, it does indeed makes my life easier too; but it’s really a pity to have such a good idea so poorly implemented. Taking your points

1. I understand their motivations to ask for bytes, kB and MB. Yet, standardization precisely consists in making choices. Here is a clear example of non-choice.
2. Yes, a system requirements fields exists; but it’s plain text. It does not add much value compared to the software description itself. Also, please note that stuff like DirectX won’t have the same name in Russian or in Japanese (again PAD is failing at internationalization)
3. Never define a standard on the lowest common denominator within an industry, otherwise you end-up with drastic limitations. Stripping HTML tags out an HTML document is super-easy anyway. Thus, there is no reason not to allow HTML.
4. OK, U.S.A. + Canada + Australia haves states (plus a couple of other countries probably); but most of the planet does not (ex: Italy, Russia, France, China, Japan, India, …).
5. and 6. You miss my point. Several download URLs is a good idea. The problem is the implementation. Clearly here, an XML list should have been used. Same remark for the screenshot URLs.March 12, 2007 | joannes