XML

1. What is XML, and why it is gaining such a momentum?

XML, or Extensible Markup Language, is an excellent way of representing data in a structured format. The most popular application of XML is for data-exchange. Like HTML, XML is also a textual, tag-based "markup" language. However, unlike HTML, which has a fixed set of tags and focuses on "presentation", XML does not have any fixed set of tags, and XML is all about "data". It is possible to create our own tags, and write data inside these tags in an XML document. The XML data is structured in a hierarchical format, and there are many "parsers" available that allow easily getting to the data values.

Some of the reasons behind XML's success include:

* The ability to define and use our own tags makes XML "extensible", and self-describing.
* XML's textual nature makes it highly portable allowing us to send and receive data from one platform to the other without any issues (such as encoding).
* The availability of many free XML parsers and processors, makes it really easy to create, read, and manage XML documents.
* As mentioned earlier, XML is all about data. Separating "presentation" from the actual "content" has many benefits, including the flexibility of providing/presenting data to multiple destinations/devices.
* The availability of various other standards surrounding the XML (such as XSLT, XPath, and XML Schema); and support for these standards in various toolkits/APIs.
* XML is the "standard" backed by W3C and supported by major vendors.

In addition to data-exchange, XML is being used for various other purposes, such as content management, XML-based configuration files, eBusiness, document publishing, application integration, and most notably XML-based messaging or Web services.

2. Take any example, such as Employees, or Customers, and write a sample XML document.





David

Johnson





The above sample XML document illustrates some good practices, such as writing XML declaration line including the encoding attribute; use of namespaces, etc; and also highlights the facts that you know about comments, attributes, etc.




3. What is the difference between well-formed and valid XML document?

W3C, in the XML specification, has defined certain rules that needs to be followed while creating XML documents. The examples of such rules include: having exactly one root element, having end-tag for each start- tag, using single/double quotes for attribute values, and so on. If an XML document follows all these rules, it is said to be well-formed document and XML parsers can be used to parse and process such documents.

Document Type Definitions (DTDs) or XML Schemas can be used to define the structure and content of a specific class of XML documents. This includes the parent-child relationship details, attribute lists, data type information, value restrictions, etc. In addition to the well-formedness rules, if an XML document also follows the rules specified in the associated DTD/Schema, it is said to be a valid XML document. All valid XML documents are well-formed; but the reverse is not always true, that is, well-formed XML documents do not necessarily have to be valid.

4. What is W3C and what is its role in the development of XML family of technologies?

World Wide Web Consortium (W3C), founded by Tim Berners-Lee (inventor of the Web), is a group of less than 100 full-time staff and about 500 members, which includes corporations, government, universities, etc. is an Internet standards body that creates recommendations such as HTML and XML. A very well-defined process is followed to take the idea and turn into a recommendation, which then requires sufficient vendor and developer support to become a successful Web technology.

W3C has divided the Web-related work into five domains (Source: W3C Web site):

* Architecture Domain: develops the underlying technologies of the Web, such as URI, DOM, XML, Web Services, etc.
* Document Formats Domain: works on formats and languages, such as HTML, CSS, MathML, SVG, etc.
* Interaction Domain: to improve user interaction with the Web, and to facilitate single Web authoring to benefit users and content providers alike; includes speech, multimedia, multimodal, etc.
* Technology and Society Domain: to develop Web infrastructure to address social, legal, and public policy concerns. Activities include Semantic Web (RDF), Platform for Privacy Preferences (P3P), XML Signature (xmldsig), XML Encryption, XML Key Management, etc.
* Web Accessibility Initiative (WAI): to lead the Web to its full potential includes promoting a high degree of usability for people with disabilities, and people not familiar with technologies, etc. This group defines guidelines for browsers, multimedia players, etc.

5. If XML is all about "text" data, is it possible to include binary data (such as an image) in an XML document? If yes, how?

Yes, it is possible to include binary data as part of XML document. The binary data needs to be hex or base64 encoded. Most of the parsers and various XML tools offer the encoding/decoding support for binary data, for example, using Microsoft's XML parser (MSXML), if a node data type is set to bin.base64, the parser automatically does the base64 encoding/decoding.

6. Is it possible to include international character (such as Japanese, or Chinese) characters inside an XML document. If yes, how?

Yes, XML being a Unicode-text-based standard supports international characters. The encoding attribute value in the XML declaration line () needs to be properly set in such cases.

7. What is the use of Namespaces in XML?

As XML does not predefine any set of tags/attribute names. Hence, it is quite possible that two totally different XML documents, defined by two totally different people/ companies, use the same tag name/attribute name. If an application needs to use (merge, process, etc.) above two XML documents together, this would cause confusion and we need a way to distinguish deterministically between tags with the same name. XML Namespaces are used for this purpose. Namespaces are defined using URI (Uniform Resource Identifier), and then associated with the element/attribute names. Namespaces are also used to "group" a logically related set of XML vocabulary.

8. Was XML created to replace HTML? Or will XML ever replace HTML?

It is a fact that the problem with HTML is that combines "data" with the "presentation" details, but XML was not necessarily created to replace HTML, rather it was created with a much broader vision – a universal format to structured data. HTML is, and will remain, the primary backbone of the Web. However, the benefits of XML will soon be seen in HTML as well, which is evolving as XHTML 1.0 (HTML 4.01 in XML syntax). So, to answer the question: No, XML was not created to replace XML and it will not completely replace HTML; however it is being used to update HTML for better Web.

9. What is XHTML?

Is simple words, XHTML, or Extensible HTML, is HTML 4 with XML rules applied to it (each begin tag must have an end tag, attribute values in single/double quotes, etc.). However, the overall vision of XHTML is much more than that. In addition to using XML syntax for HTML, XHTML also encloses specifications such as XHTML Basic (minimal set of modules for devices such as PDAs), XForms (represents the next generation of forms for the Web, and separates presentation, logic, and data), XML Events (provides XML languages with the ability to uniformly integrate event listeners and associated event handlers), etc.

10. Was XML created to replace databases, specifically RDBMS? Or will XML ever replace databases?

XML and "data" can be assumed to be synonymous, but XML was not created to replace traditional RDBMSs (Relational Database Management Systems), such as SQL Server or Oracle. XML is quite popular for "data-on-move". XML can be used to "contain", "define", and "transform" data, but it is not designed to offer benefits that traditional RDBMS offer, such as security, transaction support, etc. However, for certain applications it would make more sense to "natively" store XML. Instead of using traditional relational databases, Native XML Databases products are available in the market, that can be used to store and manage XML in its native form, for application such as content management, search, etc.

11. Was XML created to replace EDI (Electronic Data Interchange)? Or will XML ever replace EDI?

Considering the complexity, ROI, and various other disadvantages or EDI, think that XML is here to replace EDI (Electronic Data Interchange). We encourage you to read the article XML Set To Change The Face Of E-Commerce.

12. Is it possible to have characters from multiple encodings into a single XML document? If yes, how?

XML declaration line (and hence the encoding attribute) is optional in the XML document. The parser uses the first bytes (Unicode byte-order-mark) in the document to detect if the document is UTF-8 or UTF-16. If document contains characters from encoding other than UTF-8 and UTF-16, it is required to define the encoding attribute with the correct value. Once the encoding is defined for one character set, it is not possible to redefine the encoding or include data from other encoding. However, if it required to represent data from two different encodings, external entities can be used for this purpose.

13. What is XPath?

XML Path Language (XPath) is a W3C specification that defines syntax for addressing parts of XML document. XML document is considered as a logical tree structure, and syntax based on this consideration is used to address elements and attributes at any level in the XML document. For example, considering the XML document described above in answer to question 2, /abc:Employees/abc:Emp/@EmpID XPath expression can be used to access the EmpID attribute under the (first) Emp element under the Employees document element. XPath is used in various other specifications such as XSLT.

14. What is XSLT? And what's its use?

XSL Transformations (XSLT) is yet another popular W3C specification that defines XML-based syntax, used to transform XML documents to any other text format, such as HTML, text, XML, etc. XSLT stylesheets can be applied on the source XML document to transform XML into some other XML, or text, HTML, or any other text format.

15. How are DTDs/XML Schemas important while building XML applications?

Document Type Definition (DTD) or XML Schema is used to define the structure and other constrains for the XML documents. If an XML document has an associated DTD/Schema, it is said to be a valid XML document, and it ensures that the XML document structure and data adheres to the predefined rules. While using the XML document in an application, once the XML document is validated, it is then not required to assert/check for parent-child relationship, presence/absence of elements/attributes, data-value range checks, etc. The schema validation already took care of all such issues. If a valid XML document is being used as the media of data transfer between two parties, both can be rest assured that the XML document is as expected. In addition, DTDs/Schemas have many other benefits, including help in understanding the resultant XML document structure/constraints (documentation), and defining DTDs/Schemas is also a good design step.

16. What is DOM?

Document Object Model (DOM) is a W3C specification that defines a standard (abstract) programming API to build, navigate and update XML documents. It is a "tree-structure-based" interface. As per the DOM specification, the XML parsers (such as MSXML or Xerces), load the entire XML document into memory, before it can be processed. XPath is used to navigate randomly in the document, and various DOM methods are used to create and update (add elements, delete elements, add/remove attributes, etc.) the XML documents.

17. What is SAX?

Simple API for XML Processing (SAX) is an alternative to DOM, and can be used to parse XML documents. SAX is based on streaming model. The SAX parser reads input XML stream and generates various parsing events that an application can handle. With each parsing event, the parser sends sufficient information about the node being parsed. Unlike DOM, SAX does not build an in-memory representation of the source XML document, and hence it is an excellent alternative when parsing large XML documents, as SAX does not require that much memory (and resources). Unlike DOM, SAX is not defined/controlled by W3C. See http://www.saxproject.org/ for details.

18. Which is the best API to parse a huge XML document, to get parts of data from the XML document?

If the requirement is to "look-into" a huge XML document for some chunk of data, SAX would be better alternative. DOM load/unload of huge XML documents needs lot of memory and other resources, whereas SAX parses the XML character-by-character, and hence is well suited in this case.

19. Why the XML Web service is such a hot topic in the industry right now? Is it just some hype, or does it have a real value behind it?

Google (Search Web service), Amazon (for Associates, store building), Microsoft (MapPoint.NET), and many other already offer and support XML Web services. Using XML as Internet-based messaging, to integrate applications, is truly a valuable technology that offers a good ROI (considering other integration technologies and interoperability issues) and demands lower integration costs. In last two years, XML Web services received a good momentum, more and more vendors supported it, and surrounding standards were defined to close any lose gaps, making XML Web services quite a mature, low-risk technology , and think will continue in the coming years.

20. What are the core protocols/standards behind XML Web services?

XML (for message format), HTTP and others (for transport), WSDL (Web Service Definition Language, to describe the Web services and define the contract), and UDDI (Universal Description, Discovery and Integration, to dynamically discover and invoke Web services).

Differences Between XML and HTML
Table 1.

XML


HTML

User definable tags


Defined set of tags designed for web display

Content driven


Format driven

End tags required for well formed documents


End tags not required

Quotes required around attributes values


Quotes not required

Slash required in empty tags


Slash not required

Describe the role that XSL can play when dynamically generating HTML pages from a relational database.

Even if candidates have never participated in a project involving this type of architecture, they should recognize it as one of the common uses of XML. Querying a database and then formatting the result set so that it can be validated as an XML document allows developers to translate the data into an HTML table using XSLT rules. Consequently, the format of the resulting HTML table can be modified without changing the database query or application code since the document rendering logic is isolated to the XSLT rules.
Give a few examples of types of applications that can benefit from using XML.

There are literally thousands of applications that can benefit from XML technologies. The point of this question is not to have the candidate rattle off a laundry list of projects that they have worked on, but, rather, to allow the candidate to explain the rationale for choosing XML by citing a few real world examples. For instance, one appropriate answer is that XML allows content management systems to store documents independently of their format, which thereby reduces data redundancy. Another answer relates to B2B exchanges or supply chain management systems. In these instances, XML provides a mechanism for multiple companies to exchange data according to an agreed upon set of rules. A third common response involves wireless applications that require WML to render data on hand held devices.
What is DOM and how does it relate to XML?

The Document Object Model (DOM) is an interface specification maintained by the W3C DOM Workgroup that defines an application independent mechanism to access, parse, or update XML data. In simple terms it is a hierarchical model that allows developers to manipulate XML documents easily Any developer that has worked extensively with XML should be able to discuss the concept and use of DOM objects freely. Additionally, it is not unreasonable to expect advanced candidates to thoroughly understand its internal workings and be able to explain how DOM differs from an event-based interface like SAX.
What is SOAP and how does it relate to XML?

The Simple Object Access Protocol (SOAP) uses XML to define a protocol for the exchange of information in distributed computing environments. SOAP consists of three components: an envelope, a set of encoding rules, and a convention for representing remote procedure calls. Unless experience with SOAP is a direct requirement for the open position, knowing the specifics of the protocol, or how it can be used in conjunction with HTTP, is not as important as identifying it as a natural application of XML.
Can you walk us through the steps necessary to parse XML documents?

Superficially, this is a fairly basic question. However, the point is not to determine whether candidates understand the concept of a parser but rather have them walk through the process of parsing XML documents step-by-step. Determining whether a non-validating or validating parser is needed, choosing the appropriate parser, and handling errors are all important aspects to this process that should be included in the candidate's response.
Give some examples of XML DTDs or schemas that you have worked with.

Although XML does not require data to be validated against a DTD, many of the benefits of using the technology are derived from being able to validate XML documents against business or technical architecture rules. Polling for the list of DTDs that developers have worked with provides insight to their general exposure to the technology. The ideal candidate will have knowledge of several of the commonly used DTDs such as FpML, DocBook, HRML, and RDF, as well as experience designing a custom DTD for a particular project where no standard existed.
Using XSLT, how would you extract a specific attribute from an element in an XML document?

Successful candidates should recognize this as one of the most basic applications of XSLT. If they are not able to construct a reply similar to the example below, they should at least be able to identify the components necessary for this operation: xsl:template to match the appropriate XML element, xsl:value-of to select the attribute value, and the optional xsl:apply-templates to continue processing the document.

Extract Attributes from XML Data
Example 1.

Attribute Value:







When constructing an XML DTD, how do you create an external entity reference in an attribute value?

Every interview session should have at least one trick question. Although possible when using SGML, XML DTDs don't support defining external entity references in attribute values. It's more important for the candidate to respond to this question in a logical way than than the candidate know the somewhat obscure answer.
How would you build a search engine for large volumes of XML data?

The way candidates answer this question may provide insight into their view of XML data. For those who view XML primarily as a way to denote structure for text files, a common answer is to build a full-text search and handle the data similarly to the way Internet portals handle HTML pages. Others consider XML as a standard way of transferring structured data between disparate systems. These candidates often describe some scheme of importing XML into a relational or object database and relying on the database's engine for searching. Lastly, candidates that have worked with vendors specializing in this area often say that the best way the handle this situation is to use a third party software package optimized for XML data.

Obviously, some important areas of XML technologies were not included in this list -- namespaces, XPointer, XLink, and so on -- and should be added to the interviewer's set of questions if applicable to the particular position that the candidate is applying for. However, these questions in conjunction with others to assess soft skills (communication skills, ability to work on teams, leadership ability, etc.) will help determine how well candidates understand the fundamental principles of XML.
What Is an XML Web Service?

XML Web services are the fundamental building blocks in the move to distributed computing on the Internet. Open standards and the focus on communication and collaboration among people and applications have created an environment where XML Web services are becoming the platform for application integration. Applications are constructed using multiple XML Web services from various sources that work together regardless of where they reside or how they were implemented.

There are probably as many definitions of XML Web Service as there are companies building them, but almost all definitions have these things in common:

· XML Web Services expose useful functionality to Web users through a standard Web protocol. In most cases, the protocol used is SOAP.

· XML Web services provide a way to describe their interfaces in enough detail to allow a user to build a client application to talk to them. This description is usually provided in an XML document called a Web Services Description Language (WSDL) document.

· XML Web services are registered so that potential users can find them easily. This is done with Universal Discovery Description and Integration (UDDI).

I'll cover all three of these technologies in this article but first I want to explain why you should care about XML Web services.

One of the primary advantages of the XML Web services architecture is that it allows programs written in different languages on different platforms to communicate with each other in a standards-based way. Those of you who have been around the industry a while are now saying, "Wait a minute! Didn't I hear those same promises from CORBA and before that DCE? How is this any different?" The first difference is that SOAP is significantly less complex than earlier approaches, so the barrier to entry for a standards-compliant SOAP implementation is significantly lower. Paul Kulchenko maintains a list of SOAP implementations at: http://www.soapware.org/directory/4/implementations which at last count contained 79 entries. You'll find SOAP implementations from most of the big software companies, as you would expect, but you will also find many implementations that are built and maintained by a single developer. The other significant advantage that XML Web services have over previous efforts is that they work with standard Web protocols—XML, HTTP and TCP/IP. A significant number of companies already have a Web infrastructure, and people with knowledge and experience in maintaining it, so again, the cost of entry for XML Web services is significantly less than previous technologies.

We've defined an XML Web service as a software service exposed on the Web through SOAP, described with a WSDL file and registered in UDDI. The next logical question is. "What can I do with XML Web services?" The first XML Web services tended to be information sources that you could easily incorporate into applications—stock quotes, weather forecasts, sports scores etc. It's easy to imagine a whole class of applications that could be built to analyze and aggregate the information you care about and present it to you in a variety of ways; for example, you might have a Microsoft® Excel spreadsheet that summarizes your whole financial picture—stocks, 401K, bank accounts, loans, etc. If this information is available through XML Web services, Excel can update it continuously. Some of this information will be free and some might require a subscription to the service. Most of this information is available now on the Web, but XML Web services will make programmatic access to it easier and more reliable.

Exposing existing applications as XML Web services will allow users to build new, more powerful applications that use XML Web services as building blocks. For example, a user might develop a purchasing application to automatically obtain price information from a variety of vendors, allow the user to select a vendor, submit the order and then track the shipment until it is received. The vendor application, in addition to exposing its services on the Web, might in turn use XML Web services to check the customer's credit, charge the customer's account and set up the shipment with a shipping company.

In the future, some of the most interesting XML Web services will support applications that use the Web to do things that can't be done today. For example, one of the services that XML Web Services would make possible is a calendar service. If your dentist and mechanic exposed their calendars through this XML Web service, you could schedule appointments with them on line or they could schedule appointments for cleaning and routine maintenance directly in your calendar if you like. With a little imagination, you can envision hundreds of applications that can be built once you have the ability to program the Web.

For more information on XML Web services and the applications they will help you build, please see the MSDN XML Web Services Developer Center.
SOAP

Soap is the communications protocol for XML Web services. When SOAP is described as a communications protocol, most people think of DCOM or CORBA and start asking things like, "How does SOAP do object activation?" or "What naming service does SOAP use?" While a SOAP implementation will probably include these things, the SOAP standard doesn't specify them. SOAP is a specification that defines the XML format for messages—and that's about it for the required parts of the spec. If you have a well-formed XML fragment enclosed in a couple of SOAP elements, you have a SOAP message. Simple isn't it?

There are other parts of the SOAP specification that describe how to represent program data as XML and how to use SOAP to do Remote Procedure Calls. These optional parts of the specification are used to implement RPC-style applications where a SOAP message containing a callable function, and the parameters to pass to the function, is sent from the client, and the server returns a message with the results of the executed function. Most current implementations of SOAP support RPC applications because programmers who are used to doing COM or CORBA applications understand the RPC style. SOAP also supports document style applications where the SOAP message is just a wrapper around an XML document. Document-style SOAP applications are very flexible and many new XML Web services take advantage of this flexibility to build services that would be difficult to implement using RPC.

The last optional part of the SOAP specification defines what an HTTP message that contains a SOAP message looks like. This HTTP binding is important because HTTP is supported by almost all current OS's (and many not-so-current OS's). The HTTP binding is optional, but almost all SOAP implementations support it because it's the only standardized protocol for SOAP. For this reason, there's a common misconception that SOAP requires HTTP. Some implementations support MSMQ, MQ Series, SMTP, or TCP/IP transports, but almost all current XML Web services use HTTP because it is ubiquitous. Since HTTP is a core protocol of the Web, most organizations have a network infrastructure that supports HTTP and people who understand how to manage it already. The security, monitoring, and load-balancing infrastructure for HTTP are readily available today.

A major source of confusion when getting started with SOAP is the difference between the SOAP specification and the many implementations of the SOAP specification. Most people who use SOAP don't write SOAP messages directly but use a SOAP toolkit to create and parse the SOAP messages. These toolkits generally translate function calls from some kind of language to a SOAP message. For example, the Microsoft SOAP Toolkit 2.0 translates COM function calls to SOAP and the Apache Toolkit translates JAVA function calls to SOAP. The types of function calls and the datatypes of the parameters supported vary with each SOAP implementation so a function that works with one toolkit may not work with another. This isn't a limitation of SOAP but rather of the particular implementation you are using.

By far the most compelling feature of SOAP is that it has been implemented on many different hardware and software platforms. This means that SOAP can be used to link disparate systems within and without your organization. Many attempts have been made in the past to come up with a common communications protocol that could be used for systems integration, but none of them have had the widespread adoption that SOAP has. Why is this? Because SOAP is much smaller and simpler to implement than many of the previous protocols. DCE and CORBA for example took years to implement, so only a few implementations were ever released. SOAP, however, can use existing XML Parsers and HTTP libraries to do most of the hard work, so a SOAP implementation can be completed in a matter of months. This is why there are more than 70 SOAP implementations available. SOAP obviously doesn't do everything that DCE or CORBA do, but the lack of complexity in exchange for features is what makes SOAP so readily available.

The ubiquity of HTTP and the simplicity of SOAP make them an ideal basis for implementing XML Web services that can be called from almost any environment. For more information on SOAP, see the MSDN SOAP home page.
What About Security?

One of the first questions newcomers to SOAP ask is how does SOAP deal with security. Early in its development, SOAP was seen as an HTTP-based protocol so the assumption was made that HTTP security would be adequate for SOAP. After all, there are thousands of Web applications running today using HTTP security so surely this is adequate for SOAP. For this reason, the current SOAP standard assumes security is a transport issue and is silent on security issues.

When SOAP expanded to become a more general-purpose protocol running on top of a number of transports, security became a bigger issue. For example, HTTP provides several ways to authenticate which user is making a SOAP call, but how does that identity get propagated when the message is routed from HTTP to an SMTP transport? SOAP was designed as a building-block protocol, so fortunately, there are already specifications in the works to build on SOAP to provide additional security features for Web services. The WS-Security specification defines a complete encryption system.
WSDL

WSDL (often pronounced whiz-dull) stands for Web Services Description Language. For our purposes, we can say that a WSDL file is an XML document that describes a set of SOAP messages and how the messages are exchanged. In other words, WSDL is to SOAP what IDL is to CORBA or COM. Since WSDL is XML, it is readable and editable but in most cases, it is generated and consumed by software.

To see the value of WSDL, imagine you want to start calling a SOAP method provided by one of your business partners. You could ask him for some sample SOAP messages and write your application to produce and consume messages that look like the samples, but this can be error-prone. For example, you might see a customer ID of 2837 and assume it's an integer when in fact it's a string. WSDL specifies what a request message must contain and what the response message will look like in unambiguous notation.

The notation that a WSDL file uses to describe message formats is based on the XML Schema standard which means it is both programming-language neutral and standards-based which makes it suitable for describing XML Web services interfaces that are accessible from a wide variety of platforms and programming languages. In addition to describing message contents, WSDL defines where the service is available and what communications protocol is used to talk to the service. This means that the WSDL file defines everything required to write a program to work with an XML Web service. There are several tools available to read a WSDL file and generate the code required to communicate with an XML Web service. Some of the most capable of these tools are in Microsoft Visual Studio® .NET.

Many current SOAP toolkits include tools to generate WSDL files from existing program interfaces, but there are few tools for writing WSDL directly, and tool support for WSDL isn't as complete as it should be. It shouldn't be long before tools to author WSDL files, and then generate proxies and stubs much like COM IDL tools, will be part of most SOAP implementations. At that point, WSDL will become the preferred way to author SOAP interfaces for XML Web services.

An excellent description of WSDL is available, and you can find the WSDL specification at http://www.w3.org/TR/wsdl.
UDDI

Universal Discovery Description and Integration is the yellow pages of Web services. As with traditional yellow pages, you can search for a company that offers the services you need, read about the service offered and contact someone for more information. You can, of course, offer a Web service without registering it in UDDI, just as you can open a business in your basement and rely on word-of-mouth advertising but if you want to reach a significant market, you need UDDI so your customers can find you.

A UDDI directory entry is an XML file that describes a business and the services it offers. There are three parts to an entry in the UDDI directory. The "white pages" describe the company offering the service: name, address, contacts, etc. The "yellow pages" include industrial categories based on standard taxonomies such as the North American Industry Classification System and the Standard Industrial Classification. The "green pages" describe the interface to the service in enough detail for someone to write an application to use the Web service. The way services are defined is through a UDDI document called a Type Model or tModel. In many cases, the tModel contains a WSDL file that describes a SOAP interface to an XML Web service, but the tModel is flexible enough to describe almost any kind of service.

The UDDI directory also includes several ways to search for the services you need to build your applications. For example, you can search for providers of a service in a specified geographic location or for business of a specified type. The UDDI directory will then supply information, contacts, links, and technical data to allow you to evaluate which services meet your requirements.

UDDI allows you to find businesses you might want to obtain Web services from. What if you already know whom you want to do business with but you don't know what services are offered? The WS-Inspection specification allows you to browse through a collection of XML Web services offered on a specific server to find which ones might meet your needs.