2.5. XML and the World Wide Web When the Web began it was pretty simple. You entered a Web address into your browser and it displayed the page from that address. The address was a Uniform Resource Locator (URL) and the page was marked up in HTML. The W3C maintains a DTD for HTML, but many HTML documents don't conform to it. So browsers attempted to cope with errors rather than report them to the users (who couldn't correct them in any case). The Web has since diverged from that simple model, both in terms of the addresses and the delivered pages. The addressing model has gotten richer, and the pages mostly don't exist until they hit your browser. 2.5.1 Web addresses: URL and URN and URI and IRI "U R kidding!", U might think, but we R not! There really are four different things that look like URLs, and act like them as well. You can safely treat them as equivalent when reading this book, unless we make a point of the difference in a specific context. They are: URI A Uniform Resource Identifier (URI) is the basic form of address on the Web. URL The Uniform Resource Locator (URL) is the most common form of URI. URN A newer form of URI, Uniform Resource Name (URN), isn't location-dependent and perhaps will reduce the number of broken links. However, it has yet to catch on because it requires more sophisticated software support (although that doesn't stop it being used to declare namespaces, as we shall see shortly). IRI An Internationalized Resource Identifier (IRI) is a form of URI that allows non-ASCII characters. Now when you see URI in the text, you'll know that it isn't a typo! 2.5.2 Web services Web addresses can be extended to become URI references, meaning they have parameters after the actual URI, as in: http://www.amazon.com/exec/obidos/ASIN/0130651982/ref%3Dase_charlesfgoldfars/103-3982805-1512612 The reason for the parameters is because large websites no longer keep repositories of static HTML pages. Instead, they analyze the parameters to determine the information you've requested and they generate a page that contains the results. The Web address has become a request and the Web page has become a Web service. In practice, though, Web-based services that are actually offered under the name "Web services" return XML documents, not HTML. The services may offer a REST interface and/or a SOAP interface.[7] [7] REST and SOAP are explained in Chapter 19, "Web services introduction", on page 414. REST A REST Web services interface is the same as the interface to any Web resource: your service request is a URI reference that addresses the result document. SOAP The SOAP interface treats the service request and response as messages in a business transaction. The result document is encapsulated in the response message; it is not a Web resource and the service request is not its address. Office products access a REST Web service as they would any network-addressable XML document; REST requires no special treatment (although you may want to write a macro to help users build a particularly complex parameter string). Therefore, any explicitly-identified Web service support in Office is only for SOAP; in fact, for a specific variety of SOAP called "document-style". That interface is more complex than REST, for two reasons: -
The service request could be an arbitrarily complex XML document. -
Both the request and the response are wrapped in a SOAP message, itself a complex XML document that is dynamically customized for each Web service operation. In this book, we'll mention SOAP or REST explicitly unless the interface to the Web service isn't important in context. And whenever we mention external XML documents, that would also include those returned by REST Web services. 2.5.3 XHTML Another way in which Web pages are changing is that a new version of HTML is starting to be used. It retains the HTML vocabulary, but uses XML syntax. XHTML – unlike HTML – tends to be valid, as it is usually generated by software. It is used in several components of Office. | 
