Comprehensive information about Computer Programming!

XML-RPC - Summary

2019-02-23T11:44:00.005-08:00

In this tutorial, you have learnt what is XML-RPC and why do we need XML-RPC. We have discussed about its data model, as well as the request and response message format to be exchanged between the client and the server. We have given one example to demonstrate how XML-RPC client and server work to exchange information.

XML-RPC is a very simple concept with a limited set of capabilities. Those limitations are in many ways the most attractive feature of XML-RPC, as they substantially reduce the difficulty of implementing the protocol and testing its interoperability.

While XML-RPC is simple, the creative application of simple tools can create sophisticated and powerful architectures. In cases where a wide variety of different systems need to communicate, XML-RPC may be the most appropriate lowest common denominator.

What's Next?

The next step is to learn WSDL and SOAP.

WSDL

WSDL is an XML-based language for describing Web services and how to access them.

WSDL describes a web service, along with the message format and protocol details for the Web service.

If you want to learn more about WSDL, please go through our WSDL tutorial.

SOAP

SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP.

If you want to learn more about SOAP, please go through our SOAP tutorial

XML-RPC - Examples

2019-02-23T11:44:00.002-08:00

To demonstrate XML-RPC, we're going to create a server that uses Java to process XML-RPC messages, and we will create a Java client to call procedures on that server.

The Java side of the conversation uses the Apache XML Project's Apache XML-RPC, available at http://xml.apache.org/xmlrpc/

Put all the .jar files in appropriate path and let us create one client and one small XML-RPC server using JAVA.

XML-RPC Client

Let us write an XML-RPC client to call a function called sum function. This function takes two parameters and returns their sum.

import java.util.*;
import org.apache.xmlrpc.*;

public class JavaClient {
   public static void main (String [] args) {
   
      try {
         XmlRpcClient client = new XmlRpcClient("http://localhost/RPC2"); 
         Vector params = new Vector();
         
         params.addElement(new Integer(17));
         params.addElement(new Integer(13));

         Object result = server.execute("sample.sum", params);

         int sum = ((Integer) result).intValue();
         System.out.println("The sum is: "+ sum);

      } catch (Exception exception) {
         System.err.println("JavaClient: " + exception);
      }
   }
}

Let us see what has happened in the above example client.

The Java package org.apache.xmlrpc contains classes for XML-RPC Java clients and XML-RPC server, e.g., XmlRpcClient.
The package java.util is necessary for the Vector class.
The function server.execute(...) sends the request to the server. The procedure sum(17,13) is called on the server as if it were a local procedure. The return value of a procedure call is always an Object.
Here "sample" denotes a handler that is defined in the server.
Note that all the parameters of the procedure call are always collected in a Vector.
The XmlRpcClient class is constructed by specifying the "web address" of the server machine followed by /RPC2.
- localhost - means the local machine
- You can specify an IP number instead of localhost, e.g. 194.80.215.219
- You can specify a domain name like xyz.dyndns.org
- You can specify a port number along with domain name as xyz.dyndns.org:8080. The default port is 80
Note that the result of the remote procedure call is always an Object and it has to be casted to the appropriate type.
When problems occur (no connection, etc.), an Exception is thrown and it has to be caught using catch statement.

Due to the above call, a client sends the following message to the server. Note that this is handled by server.execute(...) internally and you have nothing to do with it.

<?xml version="1.0" encoding="ISO-8859-1"?>
<methodCall>
   <methodName>sample.sum</methodName>
   <params>
      <param>
         <value><int>17</int></value>
      </param>
   
      <param>
         <value><int>13</int></value>
      </param>
   </params>
</methodCall>

XML-RPC Server

Following is the source code of XML-RPC Server written in Java. It makes use of built-in classes available in org.apache.xmlrpc.*

import org.apache.xmlrpc.*;

public class JavaServer { 

   public Integer sum(int x, int y){
      return new Integer(x+y);
   }

   public static void main (String [] args){
   
      try {

         System.out.println("Attempting to start XML-RPC Server...");
         
         WebServer server = new WebServer(80);
         server.addHandler("sample", new JavaServer());
         server.start();
         
         System.out.println("Started successfully.");
         System.out.println("Accepting requests. (Halt program to stop.)");
         
      } catch (Exception exception){
         System.err.println("JavaServer: " + exception);
      }
   }
}

Let us see what we have done in the above example server.

The package org.apache.xmlrpc contains the class WebServer for a XML-RPC Server implementation.
The procedure sum that is called remotely is implemented as a public method in a class.
An instance of the same server class is then associated with a handler that is accessible by the client.
The server is initialized by the port number (here: 80).
When problems occur, an Exception is thrown and has to be caught using the catch statement.

For the call mentioned in the given example client, the server sends the following response back to the client:

<?xml version="1.0" encoding="ISO-8859-1"?>
<methodResponse>
   <params>
      <param>
         <value><int>30</int></value>
      </param>
   </params>
</methodResponse>

Now your server is ready, so compile and run it at your prompt as follows:

C:\ora\xmlrpc\java>java JavaServer
Attempting to start XML-RPC Server...
Started successfully.
Accepting requests. (Halt program to stop.)

Now to test the functionality, give a call to this server as follows:

C:\ora\xmlrpc\java>java JavaClient
30

XML-RPC - Fault Format

2019-02-23T11:43:00.002-08:00

XML-RPC faults are a type of responses. If there was a problem in processing a XML-RPC request, the methodResponse element will contain a fault element instead of a params element. The fault element, like the params element, has only a single value that indicates something went wrong. A fault response might look like:

<?xml version="1.0"?>
<methodResponse>
   <fault>
      <value><string>No such method!</string></value>
   </fault>
</methodResponse>

A fault will also have an error code. XML-RPC doesn't standardize error codes at all. You'll need to check the documentation for particular packages to see how they handle faults.

A fault response could also look like:

<?xml version="1.0"?>
<methodResponse>
   <fault>
      <value>
         <struct>
            <member>
               <name>code</name>
               <value><int>26</int></value>
            </member>
    
            <member>
               <name>message</name>
               <value><string>No such method!</string></value>
            </member>
    
         </struct>
      </value>
   </fault>
</methodResponse>

XML-RPC - Response Format

2019-02-23T11:42:00.003-08:00

Responses are much like requests, with a few extra twists. If the response is successful - the procedure was found, executed correctly, and returned results - then the XML-RPC response will look much like a request, except that the methodCall element is replaced by a methodResponse element and there is no methodName element:

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param>
         <value><double>18.24668429131</double></value>
      </param>
   </params>
</methodResponse>

An XML-RPC response can only contain one parameter.
That parameter may be an array or a struct, so it is possible to return multiple values.
It is always required to return a value in response. A "success value" - perhaps a Boolean set to true (1).

Like requests, responses are packaged in HTTP and have HTTP headers. All XML-RPC responses use the 200 OK response code, even if a fault is contained in the message. Headers use a common structure similar to that of requests, and a typical set of headers might look like:

HTTP/1.1 200 OK
Date: Sat, 06 Oct 2001 23:20:04 GMT
Server: Apache.1.3.12 (Unix)
Connection: close
Content-Type: text/xml
Content-Length: 124

XML-RPC only requires HTTP 1.0 support, but HTTP 1.1 is compatible.
The Content-Type must be set to text/xml.
The Content-Length header specifies the length of the response in bytes.

A complete response, with both headers and a response payload, would look like:

HTTP/1.1 200 OK
Date: Sat, 06 Oct 2001 23:20:04 GMT
Server: Apache.1.3.12 (Unix)
Connection: close
Content-Type: text/xml
Content-Length: 124

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param>
         <value><double>18.24668429131</double></value>
      </param>
   </params>
</methodResponse>

After the response is delivered from the XML-RPC server to the XML-RPC client, the connection is closed. Follow-up requests need to be sent as separate XML-RPC connections.

XML-RPC - Request Format

2019-02-23T11:42:00.000-08:00

XML-RPC requests are a combination of XML content and HTTP headers. The XML content uses the data typing structure to pass parameters and contains additional information identifying which procedure is being called, while the HTTP headers provide a wrapper for passing the request over the Web.

Each request contains a single XML document, whose root element is a methodCall element. Each methodCall element contains a methodNameelement and a params element. The methodName element identifies the name of the procedure to be called, while the params element contains a list of parameters and their values. Each params element includes a list of param elements which in turn contain value elements.

For example, to pass a request to a method called circleArea, which takes a Double parameter (for the radius), the XML-RPC request would look like:

<?xml version="1.0"?>
<methodCall>
   <methodName>circleArea</methodName>
      <params>
         <param>
            <value><double>2.41</double></value>
         </param>
      </params>
</methodCall>

The HTTP headers for these requests will reflect the senders and the content. The basic template looks as follows:

POST /target HTTP 1.0
User-Agent: Identifier
Host: host.making.request
Content-Type: text/xml
Content-Length: length of request in bytes

For example, if the circleArea method was available from an XML-RPC server listening at /xmlrpc, the request might look like:

POST /xmlrpc HTTP 1.0
User-Agent: myXMLRPCClient/1.0
Host: 192.168.124.2
Content-Type: text/xml
Content-Length: 169

Assembled, the entire request would look like:

POST /xmlrpc HTTP 1.0
User-Agent: myXMLRPCClient/1.0
Host: 192.168.124.2
Content-Type: text/xml
Content-Length: 169
<?xml version="1.0"?>
<methodCall>
   <methodName>circleArea</methodName>
      <params>
         <param>
            <value><double>2.41</double></value>
         </param>
      </params>
</methodCall>

It's an ordinary HTTP request, with a carefully constructed payload.

XML-RPC - Data Model

2019-02-23T11:41:00.002-08:00

The XML-RPC specification defines six basic data types and two compound data types that represent combinations of types.

Basic Data Types in XML-RPC

Type	Value	Examples
int or i4	32-bit integers between - 2,147,483,648 and 2,147,483,647.	<int>27</int> <i4>27</i4>
double	64-bit floating-point numbers	<double>27.31415</double> <double>-1.1465</double>
Boolean	true (1) or false (0)	<boolean>1</boolean> <boolean>0</boolean>
string	ASCII text, though many implementations support Unicode	<string>Hello</string> <string>bonkers! @</string>
dateTime.iso8601	Dates in ISO8601 format: CCYYMMDDTHH:MM:SS	<dateTime.iso8601> 20021125T02:20:04 </dateTime.iso8601> <dateTime.iso8601> 20020104T17:27:30 </dateTime.iso8601>
base64	Binary information encoded as Base 64, as defined in RFC 2045	<base64>SGVsbG8sIFdvcmxkIQ==</base64>

These basic types are always enclosed in value elements. Strings (and only strings) may be enclosed in a value element but omit the string element. These basic types may be combined into two more complex types, arrays, and structs. Arrays represent sequential information, while structs represent name-value pairs, much like hashtables, associative arrays, or properties.

Arrays are indicated by the array element, which contains a data element holding the list of values. Like other data types, the array element must be enclosed in a value element. For example, the following arraycontains four strings:

<value>
   <array>
      <data>
         <value><string>This </string></value>
         <value><string>is </string></value>
         <value><string>an </string></value>
         <value><string>array.</string></value>
      </data>
   </array>
</value>

The following array contains four integers:

<value>
   <array>
      <data>
         <value><int>7</int></value>
         <value><int>1247</int></value>
         <value><int>-91</int></value>
         <value><int>42</int></value>
      </data>
   </array>
</value>

Arrays can also contain mixtures of different types, as shown here:

<value>
   <array>
      <data>
         <value><boolean>1</boolean></value>
         <value><string>Chaotic collection, eh?</string></value>
         <value><int>-91</int></value>
         <value><double>42.14159265</double></value>
      </data>
   </array>
</value>

Creating multidimensional arrays is simple - just add an array inside of an array:

<value>
   <array>
      <data>
  
         <value>
            <array>
               <data>
                  <value><int>10</int></value>
                  <value><int>20</int></value>
                  <value><int>30</int></value>
               </data>
            </array>
         </value>
   
         <value>
            <array>
               <data>
                  <value><int>15</int></value>
                  <value><int>25</int></value>
                  <value><int>35</int></value>
               </data>
            </array>
         </value>
   
      </data>
   </array>
</value>

A simple struct might look like:

<value>
   <struct>
      <member>
         <name>givenName</name>
         <value><string>Joseph</string></value>
      </member>
  
      <member>
         <name>familyName</name>
         <value><string>DiNardo</string></value>
      </member>
  
      <member>
         <name>age</name>
         <value><int>27</int></value>
      </member>
   </struct>
</value>

This way you can implement almost all data types supported by any programming language.

XML-RPC - Introduction

2019-02-23T11:40:00.002-08:00

RPC stands for Remote Procedure Call. As its name indicates, it is a mechanism to call a procedure or a function available on a remote computer. RPC is a much older technology than the Web. Effectively, RPC gives developers a mechanism for defining interfaces that can be called over a network. These interfaces can be as simple as a single function call or as complex as a large API.

What is XML-RPC ?

XML-RPC is among the simplest and most foolproof web service approaches that makes it easy for computers to call procedures on other computers.

XML-RPC permits programs to make function or procedure calls across a network.
XML-RPC uses the HTTP protocol to pass information from a client computer to a server computer.
XML-RPC uses a small XML vocabulary to describe the nature of requests and responses.
XML-RPC client specifies a procedure name and parameters in the XML request, and the server returns either a fault or a response in the XML response.
XML-RPC parameters are a simple list of types and content - structs and arrays are the most complex types available.
XML-RPC has no notion of objects and no mechanism for including information that uses other XML vocabulary.
With XML-RPC and web services, however, the Web becomes a collection of procedural connections where computers exchange information along tightly bound paths.
XML-RPC emerged in early 1998; it was published by UserLand Software and initially implemented in their Frontier product.

Why XML-RPC ?

If you need to integrate multiple computing environments, but don't need to share complex data structures directly, you will find that XML-RPC lets you establish communications quickly and easily.

Even if you work within a single environment, you may find that the RPC approach makes it easy to connect programs that have different data models or processing expectations and that it can provide easy access to reusable logic.

XML-RPC is an excellent tool for establishing a wide variety of connections between computers.
XML-RPC offers integrators an opportunity to use a standard vocabulary and approach for exchanging information.
XML-RPC's most obvious field of application is connecting different kinds of environments, allowing Java to talk with Perl, Python, ASP, and so on.

XML-RPC Technical Overview

XML-RPC consists of three relatively small parts:

XML-RPC data model : A set of types for use in passing parameters, return values, and faults (error messages).
XML-RPC request structures : An HTTP POST request containing method and parameter information.
XML-RPC response structures : An HTTP response that contains return values or fault information.

We will study all these three components in the next three chapters.

WSDL - Example

2019-02-23T11:39:00.002-08:00

Given below is a WSDL file that is provided to demonstrate a simple WSDL program.

Let us assume the service provides a single publicly available function, called sayHello. This function expects a single string parameter and returns a single string greeting. For example, if you pass the parameter world then service function sayHello returns the greeting, "Hello, world!".

Example

Contents of HelloService.wsdl file −

<definitions name = "HelloService"
   targetNamespace = "http://www.examples.com/wsdl/HelloService.wsdl"
   xmlns = "http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns = "http://www.examples.com/wsdl/HelloService.wsdl"
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">
 
   <message name = "SayHelloRequest">
      <part name = "firstName" type = "xsd:string"/>
   </message>
 
   <message name = "SayHelloResponse">
      <part name = "greeting" type = "xsd:string"/>
   </message>

   <portType name = "Hello_PortType">
      <operation name = "sayHello">
         <input message = "tns:SayHelloRequest"/>
         <output message = "tns:SayHelloResponse"/>
      </operation>
   </portType>

   <binding name = "Hello_Binding" type = "tns:Hello_PortType">
      <soap:binding style = "rpc"
         transport = "http://schemas.xmlsoap.org/soap/http"/>
      <operation name = "sayHello">
         <soap:operation soapAction = "sayHello"/>
         <input>
            <soap:body
               encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
               namespace = "urn:examples:helloservice"
               use = "encoded"/>
         </input>
  
         <output>
            <soap:body
               encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
               namespace = "urn:examples:helloservice"
               use = "encoded"/>
         </output>
      </operation>
   </binding>

   <service name = "Hello_Service">
      <documentation>WSDL File for HelloService</documentation>
      <port binding = "tns:Hello_Binding" name = "Hello_Port">
         <soap:address
            location = "http://www.examples.com/SayHello/" />
      </port>
   </service>
</definitions>

Example Analysis

Definitions − HelloService
Type − Using built-in data types and they are defined in XMLSchema.
Message −
- sayHelloRequest − firstName parameter
- sayHelloresponse − greeting return value
Port Type − sayHello operation that consists of a request and a response service.
Binding − Direction to use the SOAP HTTP transport protocol.
Service − Service available at http://www.examples.com/SayHello/
Port − Associates the binding with the URI http://www.examples.com/SayHello/ where the running service can be accessed.

WSDL - Elements

2019-02-23T11:38:00.002-08:00

WSDL breaks down web services into three specific, identifiable elements that can be combined or reused once defined.

The three major elements of WSDL that can be defined separately are −

Types
Operations
Binding

A WSDL document has various elements, but they are contained within these three main elements, which can be developed as separate documents and then they can be combined or reused to form complete WSDL files.

WSDL Elements

A WSDL document contains the following elements −

Definition − It is the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the remainder of the document, and contains all the service elements described here.
Data types − The data types to be used in the messages are in the form of XML schemas.
Message − It is an abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation.
Operation − It is the abstract definition of the operation for a message, such as naming a method, message queue, or business process, that will accept and process the message.
Port type − It is an abstract set of operations mapped to one or more end-points, defining the collection of operations for a binding; the collection of operations, as it is abstract, can be mapped to multiple transports through various bindings.
Binding − It is the concrete protocol and data formats for the operations and messages defined for a particular port type.
Port − It is a combination of a binding and a network address, providing the target address of the service communication.
Service − It is a collection of related end-points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions.

In addition to these major elements, the WSDL specification also defines the following utility elements −

Documentation − This element is used to provide human-readable documentation and can be included inside any other WSDL element.
Import − This element is used to import other WSDL documents or XML Schemas.

NOTE − WSDL parts are usually generated automatically using web services-aware tools.

The WSDL Document Structure

The main structure of a WSDL document looks like this −

<definitions>
   <types>
      definition of types........
   </types>

   <message>
      definition of a message....
   </message>

   <portType>
      <operation>
         definition of a operation.......  
      </operation>
   </portType>

   <binding>
      definition of a binding....
   </binding>

   <service>
      definition of a service....
   </service>
</definitions>

A WSDL document can also contain other elements, like extension elements and a service element that makes it possible to group together the definitions of several web services in one single WSDL document.

Proceed further to analyze an example of WSDL Document.

WSDL - Introduction

2019-02-23T11:37:00.002-08:00

WSDL stands for Web Services Description Language. It is the standard format for describing a web service. WSDL was developed jointly by Microsoft and IBM.

Features of WSDL

WSDL is an XML-based protocol for information exchange in decentralized and distributed environments.
WSDL definitions describe how to access a web service and what operations it will perform.
WSDL is a language for describing how to interface with XML-based services.
WSDL is an integral part of Universal Description, Discovery, and Integration (UDDI), an XML-based worldwide business registry.
WSDL is the language that UDDI uses.
WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'.

WSDL Usage

WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in the WSDL.

History of WSDL

WSDL 1.1 was submitted as a W3C Note by Ariba, IBM, and Microsoft for describing services for the W3C XML Activity on XML Protocols in March 2001.

WSDL 1.1 has not been endorsed by the World Wide Web Consortium (W3C), however it has just released a draft for version 2.0 that will be a recommendation (an official standard), and thus endorsed by the W3C.

Java XML - Parsers

2019-02-23T11:36:00.002-08:00

XML Parsing refers to going through an XML document in order to access or modify data.

What is XML Parser?

XML Parser provides a way to access or modify data in an XML document. Java provides multiple options to parse XML documents. Following are the various types of parsers which are commonly used to parse XML documents.

Dom Parser − Parses an XML document by loading the complete contents of the document and creating its complete hierarchical tree in memory.
SAX Parser − Parses an XML document on event-based triggers. Does not load the complete document into the memory.
JDOM Parser − Parses an XML document in a similar fashion to DOM parser but in an easier way.
StAX Parser − Parses an XML document in a similar fashion to SAX parser but in a more efficient way.
XPath Parser − Parses an XML document based on expression and is used extensively in conjunction with XSLT.
DOM4J Parser − A java library to parse XML, XPath, and XSLT using Java Collections Framework. It provides support for DOM, SAX, and JAXP.

Java XML - Overview

2019-02-23T11:35:00.000-08:00

What is XML?

XML is a simple text-based language which was designed to store and transport data in plain text format. It stands for Extensible Markup Language. Following are some of the salient features of XML.

XML is a markup language.
XML is a tag based language like HTML.
XML tags are not predefined like HTML.
You can define your own tags which is why it is called extensible language.
XML tags are designed to be self-descriptive.
XML is W3C Recommendation for data storage and data transfer.

Example

<?xml version = "1.0"?>
<Class>
   <Name>First</Name>
   <Sections>
      <Section>
         <Name>A</Name>
         <Students>
            <Student>Rohan</Student>
            <Student>Mohan</Student>
            <Student>Sohan</Student>
            <Student>Lalit</Student>
            <Student>Vinay</Student>
         </Students>
      </Section>
      
      <Section>
         <Name>B</Name>
         <Students>
            <Student>Robert</Student>
            <Student>Julie</Student>
            <Student>Kalie</Student>
            <Student>Michael</Student>
         </Students>
      </Section>
   </Sections>
</Class>

Advantages

Following are the advantages that XML provides −

Technology agnostic − Being plain text, XML is technology independent. It can be used by any technology for data storage and data transfer purpose.
Human readable − XML uses simple text format. It is human readable and understandable.
Extensible − In XML, custom tags can be created and used very easily.
Allow Validation − Using XSD, DTD and XML structures can be validated easily.

Disadvantages

Following are the disadvantages of using XML −

Redundant Syntax − Normally XML files contain a lot of repetitive terms.
Verbose − Being a verbose language, XML file size increases the transmission and storage costs.

ebXML - Summary

2019-02-23T11:33:00.005-08:00

This brief tutorial covered the basics of ebXML and its various elements. We discussed the complete architecture of ebXML and how it provides consistent business semantics and a standard technical infrastructure for business exchanges. In addition, we covered how to put ebXML into use a real example.

From this tutorial we conclude:

ebXML is a worldwide project to standardize the exchange of electronic business data.
ebXML is a group of related specifications that covers analysis of Business Processes and Business Documents.
ebXML is to enable consistent, secure, and interoperable message exchange XML-based infrastructure.
ebXML is supported by hundreds of industry consortia, standards bodies, companies, and individuals from around the world.

What is Next?

Hope you have a basic understanding of ebXML. To help you learn more on this topic, we have supplied a list of useful links on our website from where you can collect more information on ebXML.

Did you find ebXML interesting? Please send us your feedback at contact@tutorialspoint.com.

ebXML - Usage Example

2019-02-23T11:33:00.002-08:00

The following diagram shows an ebXML scenario, which makes it easy to pick up the concept of ebXML. The example is taken from the Technical Architecture Specification.

The example shows how organizations prepare for ebXML, search for new trading partners and then engage in electronic business.

Company A browses the ebXML registry to see what is available online. At best, company A can reuse all the existing business processes, documents, and core components common to its industry that are already stored in the ebXML registry. Otherwise, company A designs the missing parts, stores them in the ebXML registry and makes them available for its industry partners.
Company A decides to do electronic business the ebXML way and considers implementing a local ebXML compliant application. An ebXML Business Service Interface (BSI) provides the link between the company and the outside ebXML world. The company has to create a Collaboration Protocol Profile (CPP) which describes the supported business process capabilities, constraints and technical ebXML information such as choice of encryption algorithms, encryption certificates, and choice of transport protocols.
Company A submits its CPP to ebXML registry. From that point on, company A is publicly listed in the ebXML registry and is likely to be discovered by other companies querying for new trading partners.
Company B is already registered at the ebXML registry and is looking for new trading partners. Company B queries the ebXML registry and receives the CPP of company A. Company B then has two CPP's: Company A's CPP and its own. The two companies have to come to an agreement on how to do business, which is called a Collaboration Protocol Agreement (CPA) in the ebXML terminology. Company B uses an ebXML CPA formation tool to derive a CPA from the requirements of the two CPPs
In this scenario, company B communicates with company A directly and sends the newly created CPA for acceptance to company A. Upon agreement of the CPA by company A, both companies are ready for electronic business.
The companies then use the underlying ebXML framework and exchange business documents conforming to the CPA. This means that both companies follow the business processes defined in the CPA.

ebXML - Messaging Service

2019-02-23T11:32:00.002-08:00

A complete message is called the message package, which is a Multipurpose Internet Mail Extensions (MIME) object. The message package contains two principal parts:

SOAP Message Container: This is required part of the message and contains the SOAP extension elements for ebXML, such as routing information, trading partner information, message identification, and delivery semantics information.
Payload Containers: This is optional part of the message and can contain any type of information that is to be exchanged between parties.

Messaging Design Criteria

According to the messaging service specification, the design goals for the ebXML message service are to:

Leverage existing standards wherever possible.
Be simple to implement.
Support enterprises of all sizes.
Support a wide variety of communication protocols (HTTP, SMTP, FTP, etc.)
Support payloads of any type (XML, EDI transactions, binary data, etc.)
Support reliable messaging.
Ensure security.

Messaging Architecture

The ebXML message service was designed to work within the overall context of the ebXML initiative. However, the ebXML technical architecture is modular, and the message service can be used independently of ebXML.

The ebXML message service has three logical architectural levels between the business application and the network protocols:

The Message Service Interface (MSI): It is an application interface for business applications to invoke message handler functionality for sending and receiving messages. Similar to ODBC, JDBC, and other abstract service interfaces, it exposes the message handler functionality as a defined set of APIs for business application developers.
The Message Service Handler (MSH): It has basic services, such as header processing, header parsing, security services, reliable messaging services, message packing, and error handling.
The Message Transport Interface (MTI): It is designed to send messages over various networks and application-level communication protocols. The transport interface transforms ebXML specific data to other forms carried by network services and protocols. This involves a complete exchange between two parties, piggybacking on top of existing protocols in the network stack.

The ebXML Messaging Architecture is shown in the following diagram.

Message Formatting:

An ebXML message has to be formatted according to the ebXML message service specification and must conform to the MIME syntax, format, and encoding rules. The definition of the XML elements are provided by an XML schema, which extends SOAP to define the ebXML message header, trace header, manifest, status, and acknowledgment.

Conclusion

An ebXML message has to be formatted according to the ebXML Message Service Specification and must conform to the MIME syntax, format, and encoding rules. The definition of the XML elements are provided by an XML schema, which extends SOAP to define the ebXML message header, trace header, manifest, status, and acknowledgment.

The ebXML messaging -

Uses SOAP with Attachments as payload envelope.
Runs over various communication protocols such as HTTP, SMTP, FTP.
Supports higher-level semantics needed in business transactions. (Secuirty and Reliability)

ebXML - Core Components

2019-02-23T11:31:00.002-08:00

Definition

"A Core Component captures information about a real world business concept, and relationships between that concept and other business concepts. A Core Component can be either an individual piece of business information, or a family of business information pieces. It is core because it occurs in many different areas of industry/business information exchange"

...Definition form xbXML simplified by Eric Chiu

A core component is a basic, reusable building block that contains information representing a business concept. Some examples of core components for parts of a purchase order are Date of Purchase Order, Sales Tax, and Total Amount.

In general, core components are used in many different domains, industries, and business processes. In the ebXML environment, core components are the building blocks for XML semantics and business vocabulary that are used in messages and documents.

From a specific business document in a business process, we can refer to a core component, which holds a minimal set of e-business information. If the business processes are the verbs in e-business terms, the core components represent the nouns and adjectives.

A core component can be used across several business sectors, but it also can become context-specific to a business domain, such as an individual industry area.

A core component works with a registry, since it is storable and retrievable using a standard ebXML registry. A central core component library serves as a reference document for common business practices across industry business processes.

Tools and References

The list of essential references and tools for core components provided by ebXML for the business and technical analyst is as follows:

Context and the Re-usability of Core Components: This document contains context definitions, the sources of classification value lists, and a pictorial model depicting the relationships of core component and context descriptor.
Catalog of Context Drivers: This document provides a catalog of context drivers.
Document Assembly and Context Rules: This describes the procedures and schemas for assembling documents using contextually driven core components.
Core Components Dictionary: This document is divided into sections. Each section begins with the information on the applicable category and core component type.
Core Components Editor and Browser: These tools help analysts browse existing core components and integrate them to define the format of the XML messages exchanged between trading partners and to properly define and apply the context rules.

Core Components Examples:

Core component A:
- Vendor (Industry1)
- Manufacturer (Industry 2)
- Supplier (Industry 3)
Core component B:
- Distributor (Industry 1)
- Wholesaler (Industry 2)
- Merchant (Industry 3)
Core component C:
- Store (Industry 1)
- Outlet (Industry 2)
- Retailer (Industry 3)

Conclusion

Core Components are -

Uniquely identifiable.
Reusable low-level data structures
- -e.g., party, address, phone, date, currency
- -Context-sensitive
Used to define business process and information models.
Facilitates interoperability between disparate systems.
A core component in ebXML can contain another core component.

ebXML - Registry & Repository Service

2019-02-23T11:30:00.002-08:00

An ebXML registry serves as the index and application gateway for a repository to the outside world, and it contains the API that governs how parties interact with the repository. An ebXML repository is the holder of the components.

The ebXML registry is central to the ebXML architecture.
The registry can also be viewed as an API to the database of items that supports e-business with ebXML.
The ebXML registry serves as a database for sharing relevant company information for ebXML business transactions, such as corporate capabilities, business process, technical blueprints, order forms, invoices, and so on.
Items in the repository are created, updated, or deleted through requests made to the registry.
Repositories provide trading partners with the shared business semantics.
The ebXML registry is an interface for accessing and discovering shared business semantics.
The registry interface is designed to be independent of the underlying network protocol stack, such as HTTP or SMTP over TCP/IP.

The registry provides a stable, persistent store of submitted content, which includes XML schema and documents, process descriptions, core components, context descriptions, UML models, information about parties, and even software components. This can be represented as a software stack of services, as shown below:

Goals of ebXML Registry

The goal of ebXML registry is to enable information sharing between interested parties for the purpose of business process integration between them.

Benefits of ebXML registry

An ebXML registry provides the following benefits:

Discovery and maintenance of registered content.
Support for collaborative development, where users can create XML content and submit it to the registry for use and potential enhancement by the authorized parties.
Persistence of Web Services Business Process Execution Language (WS-BPEL), WSDL, and business documents during interactions between trading partners.
Secure version control of registered content.
Federation of cooperating registries to provide a single view of registered content by seamless querying, synchronization, and relocation of registered content.
Event notification via email or Web services.

Compliance

According to the ebXML Registry Services Specification, a registry implementation complies with the ebXML specification if it meets the following conditions:

It supports the ebXML Registry Information Model.
It supports the syntax and semantics of the registry interfaces and security.
It supports the ebXML registry DTD.
Support of the syntax and semantics of SQL query in the registry is optional.

A registry client implementation complies with the ebXML specification if it meets the following conditions:

It supports the ebXML CPA and bootstrapping process.
The syntax and the semantics of the registry client interfaces.
The ebXML error message DTD.
The ebXML registry DTD.

Registry Objects and Metadata

Registry objects

Refers to an object that is submitted to registry for storage and safekeeping

called 'Repository item'
XML document or DTD, business process models, CPPs, etc.

Metadata

It is used by registry to classify and manage registry objects.
It is represented by Registry Entry

Registry Information Model (RIM)

The Registry Information Model (RIM) provides a high-level blueprint for metadata in the ebXML registry. This can be represented as a software stack of services or as a service pyramid as shown in the figure below. The elements of the information model represent meta data about the content, not the content itself in the repository. The registry information model defines the types of objects stored and organized in the registry.

The information model is a roadmap to the type of meta data and the relationships between metadata. The registry information model may be mapped to a relational database schema, object database schema, or some other physical schema.

ebXML - CPP & CPA

2019-02-23T11:29:00.005-08:00

A Collaboration Protocol Profile (CPP) provides all the necessary information on how a particular trading partner intends to do electronic business. A CPP defines the following attributes of a trading partner:

Business capabilities through business process.
The role (buyer or insurer) they play within a collaboration.
Delivery channels and transport protocols. (HTTP, SMTP, etc.)
Packaging way of business documents.
Security constraints (SSL, Digital Certificates).
Per-party configuration to business process specifications.

A CPP is stored in ebXML registry with a Globally Unique Identifier (GUID) and business partners can find each other's CPP through registry.

The information within the CPP is available to be searched on, so a potential trading partner can determine whether the organization has the capabilities to do business.

Structure of a CPP

CPP defines namespaces on its root element and a version to distinguish any subsequent changes. The structure of a CPP consists of a root Collaboration Protocol Profile element with following elements:

PartyInfo: The PartyInfo element provides information about the organization.
Packaging: The Packaging element provides information about the way in which messages are actually constructed. Messages are processed as SOAP Messages.
Signature: Optional part of the document
Comment elements: can be included.

<CollaborationProtocolProfile
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.1">
<PartyInfo>
    ...
    <!--REQUIRED, Repeatable-->
...
</PartyInfo>
<Packaging id="ID">
    ...
    <!--REQUIRED-->
    ...
<Packaging>
<ds:Signature>
    ...
    <!--OPTIONAL-->
    ...
</ds:Signature>
<Comment>
    ...
    <!-- OPTIONAL -->
    ...
</Comment>
</CollaborationProtocolProfile>

Trading Partner Agreement

A Trading Partner Agreement (TPA) is a contract defining both the legal terms and conditions and the technical specifications for both partners in the trading relationship. A CPA is derived from CPP's of trading partners.

The rules specified by the electronic TPA are independent of the business processes at either party. A technical description of the terms and conditions from the TPA is expressed in an XML document, which configures each IT systems to operate under the agreement rules.

TPA properties include its name, partner names, starting and ending dates, roles, and other parameters. Typically, one party generates a CPA and offers it to the other party for approval. Once both sides have reached agreement, they each take an electronic copy of the same CPA and use it to configure their systems.

The CPA may also be added to the registry for reference, but this is not a standard requirement.

Structure of a CPA

CPA defines namespaces on its root element and a version to distinguish any subsequent changes. The structure of a CPP consists of a root Collaboration Protocol Agreement element along with the following elements:

Start and End: These elements represent, in coordinated universal time, the beginning and end of the period during which this CPA is active.
PartyInfo: The PartyInfo element provides information about the organization. Here PartyInfo elements are included for both parties involved in the agreement.
Packaging: The Packaging element provides information about the way in which messages are actually constructed. Messages are processed as SOAP messages.
Signature: Optional part of the document.
Comment elements: can be included.

<CollaborationProtocolAgreement
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink = "http://www.w3.org/1999/xlink"
cpaid="http://www.example.com/cpas/CPAS"
version="1.7">

<Status value = "proposed"/>
<Start>1998-04-07T18:50:00</Start>
<End>1999-04-07T18:50:00</End>

<ConversationConstraints invocationLimit = "150" concurrentConversations = "10"/>

<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
</PartyInfo>

<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
</PartyInfo>

<Packaging id="N20">
    ...
    <!--REQUIRED, repeatable-->
    ...
</Packaging>

<ds:Signature>
    <!--OPTIONAL-->
</ds:Signature>

<Comment xml:lang="en-gb">
    <!--OPTIONAL-->
</Comment>
</CollaborationProtocolAgreement>

ebXML - Business Process

2019-02-23T11:29:00.002-08:00

A Business Process is something that a business does, such as buying computer parts or selling a professional service. It involves the exchange of information between two or more trading partners in some predictable way.

The specifications for business process definition enable an organization to express its business processes so that they are understandable by other organizations. It enables the integration of business processes within a company or among multiple companies.

The ebXML Business Process Specification Schema (BPSS) provides the definition of an XML document that describes how an organization conducts its business. An ebXML BPSS is a declaration of the partners, roles, collaborations, choreography, and business document exchanges that make up a business process.

Following diagram gives a conceptual view of Business Process.

Business Collaborations

A Business Collaboration is a choreographed set of business transaction activities, in which two trading partners exchange documents.

The most common one is a Binary Collaboration, in which two partners exchange documents. A Multiparty Collaboration takes place when information is exchanged between more than two parties.

Multiparty collaborations are actually choreographed Binary Collaborations.

At its lowest level, a business collaboration can be broken down into business transactions.

Business Transactions

A Business Transaction is the atomic level of work in a business process. It either succeeds or fails completely.

Business transactions are transactions in which trading partners actually transfer business documents.

Business Document Flows:

A business transaction is realized as a Business Document flows between requesting and responding roles. There is always a requesting business document, and optionally a responding business document, depending on the desired transaction semantics, for example, one-way notification vs. two-way conversation.

Actual document definition is achieved using the ebXML core component specifications, or by some methodology external to ebXML but resulting in a DTD or Schema that an ebXML business process specification can point to.

Choreography:

Choreography is expressed in terms of states and the transitions between them. A business activity is known as an abstract state, with business collaborations and business transaction activities known as concrete states. The choreography is described in the ebXML business process specification schema using activity diagram concepts such as start state, completion state etc.

Business Documents

Business documents are composed of business information objects, or smaller chunks of information that have previously been identified.

These chunks, or components, do not carry any information, of course. They are merely structures, such as an XML schema or a DTD, that define information and presentation. The end result is a predictable structure into which information is placed, so that the receiver of the final document can interpret it to extract the information.

Business Process Specification Example

A partial example of business process specification is given below:

<BusinessTransaction name="Create Order">

   <RequestingBusinessActivity name=""
      isNonRepudiationRequired="true"
      timeToAcknowledgeReceipt="P2D"
      timeToAcknowledgeAcceptance="P3D">

      <DocumentEnvelope BusinessDocument="Purchase Order"/ >
   </RequestingBusinessActivity>

   <RespondingBusinessActivity name=""
      isNonRepudiationRequired="true"
      timeToAcknowledgeReceipt="P5D">

   <DocumentEnvelope isPositiveResponse="true"
      BusinessDocument="PO Acknowledgement"/>
   </DocumentEnvelope>

   </RespondingBusinessActivity>
</BusinessTransaction>

Conclusion

A business process specification:

Describes collaboration between two partners
Defines roles, relationships and responsibilities
Defines choreography of business documents
Expressed in platform and vendor neutral format
Can be modeled with UMM (UN/CEFACT Modeling Methodology)
Formally described by Business Process Specification Schema (BPSS)
Referenced by CPP and CPA.
Refers to business document definitions.

ebXML - Architecture

2019-02-23T11:28:00.005-08:00

By definition, the iterative life cycle of B2B collaboration includes the following steps:

Process Definition
Partner Discovery
Partner Sign-up
Electronic Plug-in
Process Execution
Process Management
Process Evolution

The overall ebXML specifications are intended to cover almost the entire process of B2B collaboration and are designed to meet the needs described above.

The ebXML architecture as defined by the ebXML team provides:

A way to define business processes and their associated messages and content.
A way to register and discover business process sequences with related message exchanges.
A way to define company profiles.
A way to define trading partner agreements.
A uniform message transport layer.

Consequently, the technical architecture of ebXML is composed of five modules:

Business Process Specifications
Partner Profile and Agreements
Registry and Repository
Core Components
Messaging Service

These modules will be covered in the next five subsequent chapters. The diagram diagram shows the simplified architecture of ebXML:

ebXML - Introduction

2019-02-23T11:28:00.002-08:00

Businesses inevitably interact with each other in various ways. Until recent years, many large companies used to communicate automatically through Electronic Data Interchange (EDI), which allows two companies to communicate using predetermined signals.

The trouble with EDI is that it is very expensive and originally it was created for the mainframe world. Now ebXML is replacing EDI.

Definition

ebXML stands for Electronic Business Extensible Markup Language. It is a global standard for electronic business that enables anyone, anywhere to do business transactions with anyone over the Internet.

Features

The features of ebXML are as follows:

ebXML is an end-to-end B2B XML framework.
ebXML is a set of specifications that enable a modular framework.
ebXML relies on the Internet's existing standards such as HTTP, TCP/IP, MIME, SMTP, FTP, UML, and XML.
ebXML can be implemented and deployed on virtually any computing platform.
ebXML provides concrete specifications to enable dynamic B2B collaborations.

ebXML Vision

ebXML is designed to create a global electronic market place where enterprises of any size, anywhere can:

find each other electronically.
conduct business -
- using exchange of XML messages.
- according to standard business process sequences.
- with clear business semantics.
- using off-the-shelf purchased business applications.
- according to mutually agreed trading partner protocol agreements.

Why ebXML?

Existing B2B Frameworks are not adequate:
- EDI and RosettaNet are too heavy-weight and too rigid.
- BizTalk is proprietary, single-vendor, and single-platform.

Simple Object Access Protocol (SOAP); Web Service Definition Language (WSDL); and Universal Description, Discovery, and Integration (UDDI) alone are not adequate:
- WSDL does not address business collaboration.
- SOAP in its basic form does not provide secure and reliable message delivery.
- UDDI does not provide repository capability for business objects.

There is a growing requirement to standardize business collaborations to address the following:
- Business processes
- The parties involved in business collaboration and their roles
- Exchanging XML documents in the business collaborations
- Security, reliability, quality of service requirements of business collaboration
All these needs are addressed by ebXML.

ebXML Founding Organizations

ebXML is a joint initiative by UN/CEFACT and OASIS.

UN/CEFACT:

It stands for United Nations Centre for Trade Facilitation and Electronic Business.
It maintains the UN/EDIFACT standards for Electronic Data Interchange (EDI).

OASIS:

It stands for Organization for Advancement of Structured Information Standards.
It creates and maintains XML interoperability specifications, broad industry support.

DTD - Validation

2019-02-23T11:26:00.003-08:00

We use DTD to describe precisely the XML document. DTDs check the validity of structure and vocabulary of an XML document against the grammatical rules of the appropriate XML language. Now to check the validity of DTD, following procedures can be used −

Using XML DTD validation tools − You can use some IDEs such as XML Spy (not free) and XMLStarlet(opensource) can be used to validate XML files against DTD document.
Using XML DTD on-line validators − W3C Markup Validation Service is designed to validate Web documents. Use the online validator to check the validaty of your XML DTD here.
Write your own XML validators with XML DTD validation API − Newer versions of JDK (above 1.4) support XML DTD validation API. You can write your own validator code to check the validity of XML DTD validation.

DTD - Entities

2019-02-23T11:26:00.000-08:00

Entities are used to define shortcuts to special characters within the XML documents. Entities can be primarily of four types −

Built-in entities
Character entities
General entities
Parameter entities

Entity Declaration Syntax

In general, entities can be declared internally or externally. Let us understand each of these and their syntax as follows −

Internal Entity

If an entity is declared within a DTD it is called as internal entity.

Syntax

Following is the syntax for internal entity declaration −

<!ENTITY entity_name "entity_value">

In the above syntax −

entity_name is the name of entity followed by its value within the double quotes or single quote.
entity_value holds the value for the entity name.
The entity value of the Internal Entity is de-referenced by adding prefix & to the entity name i.e. &entity_name.

Example

Following is a simple example for internal entity declaration −

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes"?>

<!DOCTYPE address [
   <!ELEMENT address (#PCDATA)>
   <!ENTITY name "Tanmay patil">
   <!ENTITY company "TutorialsPoint">
   <!ENTITY phone_no "(011) 123-4567">
]>

<address>
   &name;
   &company;
   &phone_no;
</address>

In the above example, the respective entity names name, company and phone_no are replaced by their values in the XML document. The entity values are de-referenced by adding prefix & to the entity name.

Save this file as sample.xml and open it in any browser, you will notice that the entity values for name, company, phone_no are replaced respectively.

External Entity

If an entity is declared outside a DTD it is called as external entity. You can refer to an external Entity by either using system identifiers or public identifiers.

Syntax

Following is the syntax for External Entity declaration −

<!ENTITY name SYSTEM "URI/URL">

In the above syntax −

name is the name of entity.
SYSTEM is the keyword.
URI/URL is the address of the external source enclosed within the double or single quotes.

Types

You can refer to an external DTD by either using −

System Identifiers − A system identifier enables you to specify the location of an external file containing DTD declarations.
As you can see it contains keyword SYSTEM and a URI reference pointing to the document's location. Syntax is as follows −

<!DOCTYPE name SYSTEM "address.dtd" [...]>

Public Identifiers − Public identifiers provide a mechanism to locate DTD resources and are written as below −
As you can see, it begins with keyword PUBLIC, followed by a specialized identifier. Public identifiers are used to identify an entry in a catalog. Public identifiers can follow any format; however, a commonly used format is called Formal Public Identifiers, or FPIs.

<!DOCTYPE name PUBLIC "-//Beginning XML//DTD Address Example//EN">

Example

Let us understand the external entity with the following example −

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes"?>
<!DOCTYPE address SYSTEM "address.dtd">

<address>
   <name>
      Tanmay Patil
   </name>
   
   <company>
      TutorialsPoint
   </company>
   
   <phone>
      (011) 123-4567
   </phone>
</address>

Below is the content of the DTD file address.dtd −

<!ELEMENT address (name, company, phone)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT company (#PCDATA)>
<!ELEMENT phone (#PCDATA)>

Built-in entities

All XML parsers must support built-in entities. In general, you can use these entity references anywhere. You can also use normal text within the XML document, such as in element contents and attribute values.

There are five built-in entities that play their role in well-formed XML, they are −

ampersand: &
Single quote: '
Greater than: >
Less than: <
Double quote: "

Example

Following example demonstrates the built-in entity declaration −

<?xml version = "1.0"?>

<note>
   <description>I'm a technical writer & programmer</description>
<note>

As you can see here the & character is replaced by & whenever the processor encounters this.

Character entities

Character Entities are used to name some of the entities which are symbolic representation of information i.e characters that are difficult or impossible to type can be substituted by Character Entities.

Example

Following example demonstrates the character entity declaration −

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes"?>
<!DOCTYPE author[
   <!ELEMENT author (#PCDATA)>
   <!ENTITY writer "Tanmay patil">
   <!ENTITY copyright "&#169;">
]>
<author>&writer;&copyright;</author>

You will notice here we have used © as value for copyright character. Save this file as sample.xml and open it in your browser and you will see that copyright is replaced by the character ©.

General entities

General entities must be declared within the DTD before they can be used within an XML document. Instead of representing only a single character, general entities can represent characters, paragraphs, and even entire documents.

Syntax

To declare a general entity, use a declaration of this general form in your DTD −

<!ENTITY ename "text">

Example

Following example demonstrates the general entity declaration −

<?xml version = "1.0"?>

<!DOCTYPE note [
   <!ENTITY source-text "tutorialspoint">
]>

<note>
   &source-text;
</note>

Whenever an XML parser encounters a reference to source-text entity, it will supply the replacement text to the application at the point of the reference.

Parameter entities

The purpose of a parameter entity is to enable you to create reusable sections of replacement text.

Syntax

Following is the syntax for parameter entity declaration −

<!ENTITY % ename "entity_value">

entity_value is any character that is not an '&', '%' or ' " '.

Example

Following example demonstrates the parameter entity declaration. Suppose you have element declarations as below −

<!ELEMENT residence (name, street, pincode, city, phone)>
<!ELEMENT apartment (name, street, pincode, city, phone)>
<!ELEMENT office (name, street, pincode, city, phone)>
<!ELEMENT shop (name, street, pincode, city, phone)>

Now suppose you want to add additional eleement country, then then you need to add it to all four declarations. Hence we can go for a parameter entity reference. Now using parameter entity reference the above example will be −

<!ENTITY % area "name, street, pincode, city">
<!ENTITY % contact "phone">

Parameter entities are dereferenced in the same way as a general entity reference, only with a percent sign instead of an ampersand −

<!ELEMENT residence (%area;, %contact;)>
<!ELEMENT apartment (%area;, %contact;)>
<!ELEMENT office (%area;, %contact;)>
<!ELEMENT shop (%area;, %contact;)>

When the parser reads these declarations, it substitutes the entity's replacement text for the entity reference.

DTD - Attributes

2019-02-23T11:21:00.002-08:00

In this chapter we will discuss about DTD Attributes. Attribute gives more information about an element or more precisely it defines a property of an element. An XML attribute is always in the form of a name-value pair. An element can have any number of unique attributes.

Attribute declaration is very much similar to element declarations in many ways except one; instead of declaring allowable content for elements, you declare a list of allowable attributes for each element. These lists are called ATTLIST declaration.

Syntax

Basic syntax of DTD attributes declaration is as follows −

<!ATTLIST element-name attribute-name attribute-type attribute-value>

In the above syntax −

The DTD attributes start with <!ATTLIST keyword if the element contains the attribute.
element-name specifies the name of the element to which the attribute applies.
attribute-name specifies the name of the attribute which is included with the element-name.
attribute-type defines the type of attributes. We will discuss more on this in the following sections.
attribute-value takes a fixed value that the attributes must define. We will discuss more on this in the following sections.

Example

Below is a simple example for attribute declaration in DTD −

<?xml version = "1.0"?>

<!DOCTYPE address [
   <!ELEMENT address ( name )>
   <!ELEMENT name ( #PCDATA )>
   <!ATTLIST name id CDATA #REQUIRED>
]>

<address>
   <name id = "123">Tanmay Patil</name>
</address>

Let us go through the above code −

Begin with the XML declaration with the following statement −

<?xml version = "1.0"?>

Immediately following the XML header is the document type declaration, commonly referred to as the DOCTYPE as shown below −
The DOCTYPE informs the parser that a DTD is associated with this XML document. The DOCTYPE declaration has an exclamation mark (!) at the start of the element name.

<!DOCTYPE address [

Following is the body of DTD. Here we have declared element and attribute −

<!ELEMENT address ( name )>
<!ELEMENT name ( #PCDATA )>

Attribute id for the element name is defined as given below −
Here attribute type is CDATA and its value is #REQUIRED.

<!ATTLIST name id CDATA #REQUIRED>

Rules of Attribute Declaration

All attributes used in an XML document must be declared in the Document Type Definition (DTD) using an Attribute-List Declaration
Attributes may only appear in start or empty tags.
The keyword ATTLIST must be in upper case
No duplicate attribute names will be allowed within the attribute list for a given element.

Attribute Types

When declaring attributes, you can specify how the processor should handle the data that appears in the value. We can categorize attribute types in three main categories −

String type
Tokenized types
Enumerated types

Following table provides a summary of the different attribute types −

Sr.No.	Type & Description
1	CDATA CDATA is character data (text and not markup). It is a String Attribute Type.
2	ID It is a unique identifier of the attribute. It should not appear more than once. It is a Tokenized Attribute Type.
3	IDREF It is used to reference an ID of another element. It is used to establish connections between elements. It is a Tokenized Attribute Type.
4	IDREFS It is used to reference multiple ID's. It is a Tokenized Attribute Type.
5	ENTITY It represents an external entity in the document. It is a Tokenized Attribute Type.
6	ENTITIES It represents a list of external entities in the document. It is a Tokenized Attribute Type.
7	NMTOKEN It is similar to CDATA and the attribute value consists of a valid XML name. It is a Tokenized Attribute Type.
8	NMTOKENS It is similar to CDATA and the attribute value consists a list of valid XML name. It is a Tokenized Attribute Type.
9	NOTATION An element will be referenced to a notation declared in the DTD document. It is an Enumerated Attribute Type.
10	Enumeration It allows defining a specific list of values where one of the values must match. It is an Enumerated Attribute Type.

Attribute Value Declaration

Within each attribute declaration, you must specify how the value will appear in the document. You can specify if an attribute −

can have a default value
can have a fixed value
is required
is implied

Default Values

It contains the default value. The values can be enclosed in single quotes(') or double quotes(").

Syntax

Following is the syntax of value −

<!ATTLIST element-name attribute-name attribute-type "default-value">

where default-value is the attribute value defined.

Example

Following is a simple example of attribute declaration with default value −

<?xml version = "1.0"?>

<!DOCTYPE address [
   <!ELEMENT address ( name )>
   <!ELEMENT name ( #PCDATA )>
   <!ATTLIST name id CDATA "0">
]>

<address>
   <name id = "123">
      Tanmay Patil
   </name>
</address>

In this example we have name element with attribute id whose default value is 0. The default value is been enclosed within the double quotes.

FIXED Values

#FIXED keyword followed by the fixed value is used when you want to specify that the attribute value is constant and cannot be changed. A common use of fixed attributes is specifying version numbers.

Syntax

Following is the syntax of fixed values −

<!ATTLIST element-name attribute-name attribute-type #FIXED "value" >

where #FIXED is an attribute value defined.

Example

Following is a simple example of attribute declaration with FIXED value −

<?xml version = "1.0"?>

<!DOCTYPE address [
  <!ELEMENT address (company)*>
  <!ELEMENT company (#PCDATA)>
  <!ATTLIST company name NMTOKEN #FIXED "tutorialspoint">
]>

<address>
  <company name = "tutorialspoint">we are a free online teaching faculty</company>
</address>

In this example we have used the keyword #FIXED where it indicates that the value "tutorialspoint" is the only value for the attribute name of element <company>. If we try to change the attribute value then it gives an error.

Following is an invalid DTD −

<?xml version = "1.0"?>

<!DOCTYPE address [
  <!ELEMENT address (company)*>
  <!ELEMENT company (#PCDATA)>
  <!ATTLIST company name NMTOKEN #FIXED "tutorialspoint">
]>

<address>
  <company name = "abc">we are a free online teaching faculty</company>
</address>

REQUIRED values

Whenever you want specify that an attribute is required, use #REQUIRED keyword.

Syntax

Following is the syntax of #REQUIRED −

<!ATTLIST element-name attribute-name attribute-type #REQUIRED>

where #REQUIRED is an attribute type defined.

Example

Following is a simple example of DTD attribute declaration with #REQUIRED keyword −

<?xml version = "1.0"?>

<!DOCTYPE address [
   <!ELEMENT address ( name )>
   <!ELEMENT name ( #PCDATA )>
   <!ATTLIST name id CDATA #REQUIRED>
]>

<address>
   <name id = "123">
      Tanmay Patil
   </name>
</address>

In this example we have used #REQUIRED keyword to specify that the attribute id must be provided for the element-name name

IMPLIED Values

When declaring attributes you must always specify a value declaration. If the attribute you are declaring has no default value, has no fixed value, and is not required, then you must declare that the attribute as implied. Keyword #IMPLIED is used to specify an attribute as implied.

Syntax

Following is the syntax of #IMPLIED −

<!ATTLIST element-name attribute-name attribute-type #IMPLIED>

where #IMPLIED is an attribute type defined.

Example

Following is a simple example of #IMPLIED

<?xml version = "1.0"?>

<!DOCTYPE address [
   <!ELEMENT address ( name )>
   <!ELEMENT name ( #PCDATA )>
   <!ATTLIST name id CDATA #IMPLIED>
]>

<address>
   <name />
</address>

In this example we have used the keyword #IMPLIED as we do not want to specify any attributes to be included in element name. It is optional.

DTD - Elements

2019-02-23T11:20:00.005-08:00

XML elements can be defined as building blocks of an XML document. Elements can behave as a container to hold text, elements, attributes, media objects or mix of all.

A DTD element is declared with an ELEMENT declaration. When an XML file is validated by DTD, parser initially checks for the root element and then the child elements are validated.

Syntax

All DTD element declarations have this general form −

<!ELEMENT elementname (content)>

ELEMENT declaration is used to indicate the parser that you are about to define an element.
elementname is the element name (also called the generic identifier) that you are defining.
content defines what content (if any) can go within the element.

Element Content Types

Content of elements declaration in a DTD can be categorized as below −

Empty content
Element content
Mixed content
Any content

Empty Content

This is a special case of element declaration. This element declaration does not contain any content. These are declared with the keyword EMPTY.

Syntax

Following is the syntax for empty element declaration −

<!ELEMENT elementname EMPTY >

In the above syntax −

ELEMENT is the element declaration of category EMPTY
elementname is the name of empty element.

Example

Following is a simple example demonstrating empty element declaration −

<?xml version = "1.0"?>

<!DOCTYPE hr[
   <!ELEMENT address EMPTY>    
]>
<address />

In this example address is declared as an empty element. The markup for address element would appear as <address />.

Element Content

In element declaration with element content, the content would be allowable elements within parentheses. We can also include more than one element.

Syntax

Following is a syntax of element declaration with element content −

<!ELEMENT elementname (child1, child2...)>

ELEMENT is the element declaration tag
elementname is the name of the element.
child1, child2.. are the elements and each element must have its own definition within the DTD.

Example

Below example demonstrates a simple example for element declaration with element content −

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes" ?>

<!DOCTYPE address [
   <!ELEMENT address (name,company,phone)>
   <!ELEMENT name (#PCDATA)>
   <!ELEMENT company (#PCDATA)>
   <!ELEMENT phone (#PCDATA)>
]>

<address>
   <name>Tanmay Patil</name>
   <company>TutorialsPoint</company>
   <phone>(011) 123-4567</phone>
</address>

In the above example, address is the parent element and name, company and phone_no are its child elements.

List of Operators and Syntax Rules

Below table shows the list of operators and syntax rules which can be applied in defining child elements −

Operator	Syntax	Description	Example
+	<!ELEMENT element-name (child1+)>	It indicates that child element can occur one or more times inside parent element.	<!ELEMENT address (name+)> Child element name can occur one or more times inside the element name address.
*	<!ELEMENT element-name (child1*)>	It indicates that child element can occur zero or more times inside parent element.	<!ELEMENT address (name)> Child element name* can occur zero or more times inside the element name address.
?	<!ELEMENT element-name (child1?)>	It indicates that child element can occur zero or one time inside parent element.	<!ELEMENT address (name?)> Child element name can occur zero or one time inside the element name address.
,	<!ELEMENT element-name (child1, child2)>	It gives sequence of child elements separated by comma which must be included in the the element-name.	<!ELEMENT address (name, company)> Sequence of child elements name, company, which must occur in the same order inside the element name address.
\|	<!ELEMENT element-name (child1 \| child2)>	It allows making choices in the child element.	<!ELEMENT address (name \| company)> It allows you to choose either of child elements i.e. name or company, which must occur in inside the element name address.

Rules

We need to follow certain rules if there is more than one element content −

Sequences − Often the elements within DTD documents must appear in a distinct order. If this is the case, you define the content using a sequence.
The declaration indicates that the <address> element must have exactly three children - <name>, <company>, and <phone> - and that they must appear in this order. For example −

<!ELEMENT address (name,company,phone)>

Choices − Suppose you need to allow one element or another, but not both. In such cases you must use the pipe (|) character. The pipe functions as an exclusive OR. For example −

<!ELEMENT address (mobile | landline)>

Mixed Element Content

This is the combination of (#PCDATA) and children elements. PCDATA stands for parsed character data, that is, text that is not markup. Within mixed content models, text can appear by itself or it can be interspersed between elements. The rules for mixed content models are similar to the element content as discussed in the previous section.

Syntax

Following is a generic syntax for mixed element content −

<!ELEMENT elementname (#PCDATA|child1|child2)*>

ELEMENT is the element declaration tag.
elementname is the name of the element.
PCDATA is the text that is not markup. #PCDATA must come first in the mixed content declaration.
child1, child2.. are the elements and each element must have its own definition within the DTD.
The operator (*) must follow the mixed content declaration if children elements are included
The (#PCDATA) and children element declarations must be separated by the (|) operator.

Example

Following is a simple example demonstrating the mixed content element declaration in a DTD.

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes" ?>

<!DOCTYPE address [
   <!ELEMENT address (#PCDATA|name)*>
   <!ELEMENT name (#PCDATA)>
]>

<address>
   Here's a bit of text mixed up with the child element.
   <name>
      Tanmay Patil
   </name>
</address>

ANY Element Content

You can declare an element using the ANY keyword in the content. It is most often referred to as mixed category element. ANY is useful when you have yet to decide the allowable contents of the element.

Syntax

Following is the syntax for declaring elements with ANY content −

<!ELEMENT elementname ANY>

Here, the ANY keyword indicates that text (PCDATA) and/or any elements declared within the DTD can be used within the content of the <elementname> element. They can be used in any order any number of times. However, the ANY keyword does not allow you to include elements that are not declared within the DTD.

Example

Following is a simple example demonstrating the element declaration with ANY content −

<?xml version = "1.0" encoding = "UTF-8" standalone = "yes" ?>

<!DOCTYPE address [
   <!ELEMENT address ANY>
]>

<address>
   Here's a bit of sample text
</address>