Maybe Ours is The Language of The Future

When I explain to people what a web service is and does I try and explain it as the difference between what a human can do with the internet and what a computer program can do with the internet. It goes like this: if you're a human, and you want information about a book, you go to Amazon.com and search for the title or the author in the little search bar at the top, and it leads you to the page with the book on it. You do this because Amazon is a great bibliographic reference, by virtue of the fact that they sell just about every book that exists. If, on the other hand, you're a computer program, and are trying to assemble a library database for somebody, you're a little hamstrung. Even with an internet connection, you don't know how to use a web browser, and programming you to understand how to use the search bar and enter search terms and then read the page that came up--things that come (relatively) naturally to a human being--would take forever. Enter the web service: it provides you with an interface across the internet to, e.g., all of the book information at Amazon, in a way that a computer program can easily access and translate.

Web services, as you might expect, had to come up with a common language that everybody spoke (they also should have come up with a common protocol, like http, but in fact there are at least four that I know of, a few essentially open-source ones, and SOAP, which was developed by...wait for it...Microsoft). What they (where "they" = "The W3 Consortium") came up with is the WSDL. A WSDL (we pronounce that 'WIZ-dul' because that's just how high is our level of dork) is an XML document, because XML is apparently the wave of the future. The WSDL for the web service I described above is here.
Here's a little chunk of it:

<xs:element name="Items">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="tns:Request" minOccurs="0"/>
   <xs:element ref="tns:CorrectedQuery" minOccurs="0"/>
   <xs:element name="TotalResults" type="xs:nonNegativeInteger" 
                  minOccurs="0"/>
   <xs:element name="TotalPages" type="xs:nonNegativeInteger" 
                  minOccurs="0"/>
   <xs:element ref="tns:SearchResultsMap" minOccurs="0"/>
   <xs:element ref="tns:Item" minOccurs="0" maxOccurs="unbounded"/>
   <xs:element ref="tns:SearchBinSets" minOccurs="0"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>

This is the data type of some information that would come back from a search request. You, as a human being, probably look at this and think a) it looks like HTML code (or XML code, if you're riding the wave of the future), and b) it's pretty much gibberish. Which is ironic, because a WSDL is primarily language for humans.

It's language for computers, too, obviously--there are parsers in most programming languages that can read in a WSDL document and produce code libraries to use so that you can call the web service. But that hasn't turned out to be the primary function of the WSDL; the primary function of the WSDL is for me, the human writing the computer program that uses the web service, to understand what the web service does and how it does it. If you speak Wiz-dul, you can look at tags and symbols in this document and understand amidst the gibberish that if you send a request to the webservice and name it, "ItemSearch," and include with it labeled information about the author, artist, composer, or conductor of the item you're searching for (e.g. "Artist='U2'" or "Author='Italo Calvino'") that the service on the other side will understand you and respond in kind with a labelled list of albums or books. You don't need any other documentation than that one page of nicely indented tags.

I'm sure it wasn't the original intent of the WSDL to enable computer programmers to talk to each other about the services they offer; it's become an accidental solution to the nearly intractable problem of creating understandable technical documents about computer code. You've probably never had to read a document from a technical writer that uses English to try and describe what computer code does. You have lived a happier life never having had to do this. You have lived a much, much happier life never having had to write such a document. I don't know if this is a sign of things to come, but XML might turn out to be a model that solves this problem of language quite nicely.

Next: Somewhat more frequent posts!
Tags: Web 2.0, XML, Language