Schema for Software
I’d like you to think a moment about a recurring pattern of chaos, definition, and discovery. In each of the following instances there was a perceived sense of chaos which prompted people to develop document definitions. From those definitions technologies have been developed to allow discovery, sorting, and many new applications to facilitate searching and data acquisition.
- We have schema for protocols like RSS which meticulously describe how syndicated data is supposed to be defined. Readers were then written to allow people to easily find content using these definitions.
- We have WSDL which defines Web Services which may be consumed, and UDDI allows people to search for services that match their needs for data handling.
- For EDI there are the X12 and RosettaNet standards for every type of business transaction. OASIS provides similar definitions for XML documents for communications and other purposes.
I am not aware of any schema which has been universally embraced which defines software. When I’m looking for software, I have certain requirements, or at least I’m aware of some factors where I have some versatility:
- Operating Systems
- Win98, WinNT, WinXP, Vista, OSX, Linux, AIX…
- Processors
- 32bit, 64bit, Intel, Athlon, PowerPC…
- Source
- Closed, available with restrictions, Open
- Cost
- None, Support only, fully commercial
- Support status
- Commercial, individual developer, community
- Maintenance status
- Current, End-of-Life, no changes in last N months
- Development status
- Alpha, Beta, Production
- Versions
- Major.Minor.Build (1.2.654, 2.0.432, etc)
If all software providers updated an XML document on their website for subsequent syndication, the public could much more easily find new products, and find updates to existing products. As it is, you don’t know your software is being updated unless the developer has you on a list or you check with them proactively.
What if you have software running and you need to know if there is an update? Many software products these days have a sort of "phone home" function which makes an HTTP call, maybe using a Web Service, to check with the vendor to see if there is an update. If the vendor provides an XML-based structured software definition in addition to (or instead of) the online connection, then you could have some other piece of syndication-like software find the vendor.
Why is that better? What if the vendor is gone? What if some other company bought them out and the connection to the vendor no longer works? With a more general document describing the software, rather than a hard-coded and vendor-specific connection that provides limited functionality, you could also find consultants who can work with that product, plugins that match your environment, news about End-of-Life or ongoing enhancements, comments about recent releases, alternative availability and pricing, etc.
This also helps vendors to find out what people are looking for. Are lots of people looking for an email client but skipping by yours? Is everyone going to someone other than you for support for your product? Are you unprepared for all of those requests for the next version of your software? This all implies that vendors have some idea of how many times people see their name in a search. We already do this now when we look at website stats, and bloggers are quite familiar with trackbacks, which let one blogger know that someone else is referring to them.
Obvious issues
Email was a good idea back in the 70’s. Today we continue to use the same protocols that were developed decades ago, and billions of dollars every year are spent on fighting the related problems. My point is that a good idea only continues to be good if those who support it keep ahead of the bad guys.
What if some hacker corrupts your XML software definition so that it no longer identifies valid suppliers? What if someone falsely claims to be the developer? What if a repository of providers gets hacked to make it useless to people looking for updates or services? What if someone uses a search tool to massively ping some supplier into thinking that their product is now wildly in demand?
A project like this needs a lot of careful definition, infrastructure built around it, and ongoing vigilance for various means that can be used to corrupt the protocols. I have no intent to provide a thorough treatise here on the topic, I do think we can use something like this, and hoping someone points me to an existing project – or pays me lots of money to develop the idea. The technology exists, it’s just a matter of using it.
1 thought on “Schema for Software”
Leave a Reply
You must be logged in to post a comment.
I just found this spec for PAD, the Portable Application Description: http://www.asp-shareware.org/pad/. It looks very close to what I described in this post. OK, so it’s been around since 2004, but it’s not "universally embraced" so it took a while to find. Now I’m wondering if the MV market can use something like this to define applications for a new application directory.