[CONTACT]

[ABOUT]

[POLICY]

[ADVERTISE]

DOCTYPE HTML PUBLIC html.doctype

Found at: ftp.icm.edu.pl:70/packages/normos/w3c/NOTE-widl-970922

<!DOCTYPE HTML PUBLIC "html.dtd">
<HTML>
<!doctype  html public "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
  <META CONTENT="text/html; charset=ISO-8859-1" HTTP-EQUIV="Content-Type">
  <TITLE>Web Interface Definition Language Submission</TITLE>
  <BASE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<H1>
  <A HREF="http://www.w3.org/"><IMG HEIGHT="48" ALT="W3C" BORDER="0" WIDTH="72" SRC="http://www.w3.org/Icons/w3c_home"></A>
</H1>
<P ALIGN="right">
<B><BIG>NOTE-widl-970922</BIG></B>
<H1 ALIGN="center">
  Web Interface Definition Language (WIDL)
</H1>
<H3>
  <A HREF="http://www.w3.org/Submission/1997/15/">Submitted to W3C 22 September 1997</A>
</H3>
<DL>
  <DT>
    This version:
  <DD>
    <A HREF="NOTE-widl-970922" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922"> http://www.w3.org/TR/NOTE-widl-970922</A>
  <DT>
    Latest Version:
  <DD>
    <A HREF="NOTE-widl" W3MIRHREF="http://www.w3.org/TR/NOTE-widl"> http://www.w3.org/TR/NOTE-widl</A>
  <DT>
    Authors:
  <DD>
    Phillip Merrick, webMethods,
    <A HREF="mailto:/phillip@webMethods.com">phillip@webMethods.com</A>
  <DD>
    Charles Allen, webMethods,
    <A HREF="mailto:/caallen@webMethods.com">caallen@webMethods.com</A>
</DL>
<H2>
  Status of this Document
</H2>
<P>
This document is a NOTE made available by the W3 Consortium for discussion
only. This indicates no endorsement of its content, nor that the Consortium
has, is, or will be allocating any resources to the issues addressed by the
NOTE.
<P>
This document is a submission to W3C from
<A HREF="http://www.webmethods.com/">webMethods</A>, Inc.. Please see
<A HREF="http://www.w3.org/Submission/">Acknowledged Submissions to W3C</A> regarding its
disposition.
<P>
Copyright (c) 1997 webMethods, Inc.
<H2>
  <A NAME="abstract">Abstract</A>
</H2>
<P>
This document provides the specification for the Web Interface Definition
Language (WIDL), a metalanguage that implements a service-based architecture
over the document-based resources of the World Wide Web. WIDL is an application
of the eXtensible Markup Language (XML); it allows interactions with Web
servers to be defined as functional interfaces that can be accessed by remote
systems over standard Web protocols, and provides the structure necessary
for generating client code in languages such as Java, C/C++, COBOL, and Visual
Basic. WIDL enables a practical and cost-effective means for diverse systems
to be rapidly integrated across corporate intranets, extranets, and the Internet.
<P>
  <HR>
<H2>
  Contents
</H2>
<DL>
  <DD>
    1. <A HREF="#Introduction" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#Introduction">Introduction</A>
  <DD>
    2. <A HREF="#Usage" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#Usage">Benefits of WIDL</A>
    <DL>
      <DD>
	2.1 <A HREF="#integration" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#integration">Business-to-Business Integration</A>
      <DD>
	2.2 <A HREF="#changeManagement" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#changeManagement">Change Management</A>
      <DD>
	2.3 <A HREF="#languageBindings" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#languageBindings">Language Bindings</A>
    </DL>
  <DD>
    3. <A HREF="#references" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#references">Object Model References</A>
  <DD>
    4. <A HREF="#Example" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#Example">WIDL Examples</A>
    <DL>
      <DD>
	4.1 <A HREF="#templates" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#templates">Interface Templates</A>
      <DD>
	4.2 <A HREF="#timeouts" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#timeouts">Service Timeouts</A>
      <DD>
	4.3 <A HREF="#bindings" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#bindings">Bindings</A>
      <DD>
	4.4 <A HREF="#formNames" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#formNames">FORM Names</A>
      <DD>
	4.5 <A HREF="#headers" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#headers">HTTP Headers</A>
      <DD>
	4.6 <A HREF="#internalVariables" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#internalVariables">Internal Variables</A>
      <DD>
	4.7 <A HREF="#regions" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#regions">Regions</A>
      <DD>
	4.8 <A HREF="#conditions" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#conditions">Conditions</A>
      <DD>
	4.9 <A HREF="#rebind" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#rebind">Multiple Bindings</A>
      <DD>
	4.10 <A HREF="#serviceChains" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#serviceChains">Service Chains</A>
    </DL>
  <DD>
    5. <A HREF="#Reference" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#Reference">WIDL Reference</A>
    <DL>
      <DD>
	5.1 <A HREF="#WIDL" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#WIDL">WIDL Element</A>
      <DD>
	5.2 <A HREF="#SERVICE" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#SERVICE">SERVICE Element</A>
      <DD>
	5.3 <A HREF="#BINDING" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#BINDING">BINDING Element</A>
      <DD>
	5.4 <A HREF="#VARIABLE" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#VARIABLE">VARIABLE Element</A>
      <DD>
	5.5 <A HREF="#CONDITION" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#CONDITION">CONDITION Element</A>
      <DD>
	5.6 <A HREF="#REGION" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#REGION">REGION Element</A>
    </DL>
  <DD>
    6. <A HREF="#conclusion" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#conclusion">Conclusion</A>
  <DD>
    7. <A HREF="#References" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#References">References</A>
  <DD>
    <A HREF="#WIDL%20DTD" W3MIRHREF="http://www.w3.org/TR/NOTE-widl-970922#WIDL%20DTD">Appendix A - WIDL DTD</A>
</DL>
<P>
  <HR>
<H2>
  1. <A NAME="Introduction">Introduction</A>
</H2>
<P>
The World Wide Web is providing millions of end-users access to ever-increasing
volumes of information. While the Web initially served browsers static documents,
the resources of legacy systems, relational databases and multi-tier applications
have all been made available to the Web browser to provide corporate users
with interactive information resources including financial services, inventory
management, on-line purchasing and package tracking.
<P>
While the Web has achieved the extraordinary feat of providing ubiquitous
accessibility to end-users, it has in many cases reinforced manual inefficiencies
in business processes as repetitive tasks are required to transcribe or copy
and paste data from browser windows into desktop and corporate applications.
This is as true of Web data provided by remote business units and external
(i.e. partner or supplier) organizations as it is of Web data accessible
from both public and subscription based Web sites. The problem of direct
access to Web data from within business applications has been largely ignored.
<P>
The purpose of the Web Interface Definition Language (WIDL) is to enable
automation of all interactions with HTML/XML documents and forms, providing
a general method of representing request/response interactions over standard
Web protocols, and allowing the Web to be utilized as a universal integration
platform.
<P>
A central feature of WIDL is that programmatic interfaces can be
<I>defined</I> and <I>managed</I> for data (HTML, XML or text files) and
services (CGI-bin, database, or other back end systems) that are not under
the direct control of programs that require such access. WIDL definitions
can be co-located with client programs, centrally managed in a client/server
architecture, or referenced directly from HTML/XML documents.
<P>
WIDL defintions provide a mapping between Web resources and applications
written in conventional programming languages such as C/C++, COBOL, Visual
Basic, Java, JavaScript, etc., enabling automatic and structured Web access
by compatible client programs, including mainstream business applications,
desktop applications, applets, Web agents, and server-side Web programs (CGI,
etc.).
<P>
<I>Automatic </I>means that complex interactions with Web servers do not
require human intervention; programs can request Web data and services by
making local calls to functions which encapsulate standard Web access protocols
and utilize WIDL definitions to provide naming services, change management,
error handling, condition processing and intelligent data binding.
<P>
<I>Structured</I> means that Web data and services are described as interfaces
with well defined input and output variables.
<P>
<I>Standard Web access protocols</I> means HTTP and HTTPS.
<P>
<I>Compatible</I> means any program that both utilizes WIDL definitions to
define the location of Web services and the structure of data that is returned
by standard HTTP and HTTPS requests, and allows WIDL definitions to be managed
locally, centrally, or by individual service providers.
<P>
WIDL describes business objects on the Web, providing the basis for a common
API across Web servers, legacy systems, databases, and middleware
infrastructures, and effectively transforming the Web from an access medium
into an integration platform.
<P>
This document provides a complete description of the Web Interface Definition
Language (WIDL).
<P>
  <HR>
<H2>
  2. <A NAME="Usage">Benefits of WIDL</A>
</H2>
<P>
A major part of the value of an Interface Defintion Language (IDL) is that
it can define services offered by applications in an abstract but highly
usable fashion. WIDL brings to the Web many of the features of IDL concepts
that have been implemented in distributed computing and transaction processing
platforms including DCE, and CORBA.
<H3>
  2.1 <A NAME="integration">Business-to-Business Integration</A>
</H3>
<P>
WIDL makes it easy for organizations to automate business transactions with
customers and suppliers. WIDL describes and automates interactions with services
hosted by Web servers on intranets, extranets and the Internet; it transforms
the Web into a standard integration platform and provides a universal API
for all Web-enabled systems.
<P>
Using HTML, XML, HTTP and HTTPS as corporate standards glue, WIDL requires
only that target systems be Web-enabled. There are hundreds of products in
the market today which Web-enable existing systems, from mainframes to
client/server applications. The use of standard Web technologies empowers
various IT departments to make independent technology selections. This has
the effect of lowering both the technical and 'political' barriers that have
typically derailed cross-organizational integration projects.
<P>
A number of analysts have already warned that proprietary e-commerce platforms
could lock suppliers into relationships by forcing them to integrate their
systems with one infrastructure for business-to-business integration, making
it costly for them to switch to or integrate with other partners who have
selected alternate e-commerce platforms. Buyer-supplier integration issues
involve many-to-many relationships, and demand a standard platform for functional
integration and data exchange.
<P>
A service defined by WIDL is equivalent to a function call in standard
programming languages. At the highest level, WIDL files describe the locations
(URLs) of services, input parameters to be submitted (via <U>Get</U> or
<U>Post</U> methods) to each service, conditions for successful processing,
and output parameters to be returned by each service.
<P>
WIDL provides the following features:
<UL>
  <LI>
    A browser is not required to drive Web applications
  <LI>
    WIDL definitions are dynamically interpreted and can be centrally managed
  <LI>
    Client applications are insulated from changes in service locations and data
    extraction methods
  <LI>
    Developers are insulated from network programming concerns
  <LI>
    Application resources can be integrated through firewalls and proxies
</UL>
<P>
WIDL can be used to describe interfaces and services for:
<UL>
  <LI>
    Static documents (HTML, XML, and plain text files)
  <LI>
    Dynamically generated documents (HTML, XML, and plain text files)
  <LI>
    HTML forms
  <LI>
    URL directory structures
</UL>
<P>
WIDL can be used:
<UL>
  <LI>
    to automate interactions with Web servers
  <LI>
    for both on-demand and scheduled extraction of targeted Web data
  <LI>
    to aggregate data from a number of Web sources
  <LI>
    to chain services across multiple Web sites
  <LI>
    to rapidly integrate Web resources with traditional application development
    languages and environments
</UL>
<P>
WIDL has the ability to specify conditions for successful processing, and
error messages to be returned to calling programs. Conditions further enable
services to be defined that span multiple documents.
<H3>
  2.2 <A NAME="changeManagement">Change Management</A>
</H3>
<P>
One of WIDL's most significant benefits is its ability to insulate client
programs from changes in the format and location of Web documents. Unlike
the way CORBA and DCE IDL are normally used, WIDL is interpreted at runtime;
as a result, service URLs, object references in variables, definitions of
document regions, success/failure conditions, and directives for service
chaining can all be administered without requiring modification of client
code. This usage model supports application-to-application linkages that
are far more robust and maintainable than if they were coded by hand.
<P>
There are three models for WIDL management:
<UL>
  <LI>
    client side - where WIDL files are co-located with a client program
  <LI>
    naming service - where WIDL definitions are centrally managed and referenced
    via directory services, i.e. LDAP
  <LI>
    server side - where WIDL files are referenced by, co-located with, or embedded
    within Web documents.
</UL>
<P>
WIDL does not require that existing Web resources be modified in any way.
Flexible management models allow organizations to describe and integrate
Web sites that are uncontrolled, as well as to provide their business partners
with interfaces to services that are controlled. The ability to seamlessly
migrate from independent to shared management eases the transition from informal
to formal business-to-business integration.
<H3>
  2.3 <A NAME="languageBindings">Language Bindings</A>
</H3>
<P>
The primary purpose of WIDL is integration of Web resources with corporate
business applications. In much the same way that DCE or CORBA IDL is used
to generate code fragments, or 'stubs', to be included in application development
projects, WIDL provides the structure necessary for generating client code
in languages such as C/C++, Java, COBOL, and Visual Basic. Developers can
thus be insulated from the need to understand both HTML/XML parsing and Web
protocols. This capability enables the existing skills of innumerable programmers
to be rapidly leveraged in the utilization of Web based resources.
<P>
  <HR>
<H2>
  3. <A NAME="references">Object Model References</A>
</H2>
<P>
Many of the features of WIDL require a capability to reliably identify and
extract specific data elements from Web documents. Various mechanisms for
accessing elements of HTML and/or XML documents have been defined, such as
the Javascript Page Object Model, the Document Object Model, and XLL XPointers.
WIDL does not define or determine a mechanism for accessing document data,
but rather allows an object model referencing mechanism to be specified on
a per-interface basis.
<P>
The following capabilities are desirable for accessing elements of Web documents:
<UL>
  <LI>
    HTML Parsing
  <LI>
    XML Parsing
  <LI>
    Text Pattern Matching
</UL>
<P>
Object referencing mechanisms would ideally support both parsing and pattern
matching. Pattern matching extracts data based on regular expressions, and
is well suited to raw text files and poorly constructed HTML documents. Parsing,
on the other hand, recovers document structure and exposes relationships
between document objects, enabling elements of a document to be accessed
with an object model.
<P>
  <HR>
<H2>
  4. <A NAME="Example">WIDL Examples</A>
</H2>
<P>
The following example illustrates the use of WIDL to define a package tracking
service for generic Shipping. By allowing a WIDL definition to reference
a 'Template' WIDL definition, a general class of shipping services can be
defined. 'FoobarShipping' is one implementation of the 'Shipping' interface.
<P>
<PRE>
    &lt;WIDL NAME="genericShipping" TEMPLATE="Shipping"
          BASEURL="http://www.shipping.com" VERSION="2.0"&gt;

		
    &lt;SERVICE NAME="TrackPackage" METHOD="Get" 
             URL="/cgi-bin/track_package"
             INPUT="TrackInput" OUTPUT="TrackOutput" /&gt;

		
    &lt;BINDING NAME="TrackInput" TYPE="INPUT"&gt;
       &lt;VARIABLE NAME="TrackingNum" TYPE="String" FORMNAME="trk_num" /&gt;
       &lt;VARIABLE NAME="DestCountry" TYPE="String" FORMNAME="dest_cntry" /&gt;
       &lt;VARIABLE NAME="ShipDate" TYPE="String" FORMNAME="ship_date" /&gt;
    &lt;/BINDING&gt;

		
    &lt;BINDING NAME="TrackOutput" TYPE="OUTPUT"&gt;
       &lt;CONDITION TYPE="Failure" REFERENCE="doc.title[0].text" 
                  MATCH="Warning Form" REASONREF="doc.p[0].text" /&gt;
       &lt;CONDITION TYPE="Success" REFERENCE="doc.title[0].text" 
                  MATCH="Foobar Airbill:*" REASONREF="doc.p[1].value" /&gt;
       &lt;VARIABLE NAME="disposition" TYPE="String" REFERENCE="doc.h[3].value" /&gt;
       &lt;VARIABLE NAME="deliveredOn" TYPE="String" REFERENCE="doc.h[5].value" /&gt;
       &lt;VARIABLE NAME="deliveredTo" TYPE="String" REFERENCE="doc.h[7].value" /&gt;
    &lt;/BINDING&gt;

		
    &lt;/WIDL&gt;
</PRE>
<P>
In this example, the values defined in the 'TrackInput' binding get passed
via HTTP Get as name-value pairs to a service residing at
'http://www.shipping.com/cgi-bin/track_package'. Object References are used
in the 'TrackOutput' binding to a) check for successful completion of the
service, and b) extract data elements from the document returned by the HTTP
request.
<H3>
  4.1 <A NAME="templates">Interface Templates</A>
</H3>
<P>
WIDL enables common interfaces to services provided by multiple sites. Templates
allow the specification of interfaces, implementations of which may be available
from multiple sources. A shipping template defines a functional interface
for shipping services; various implementations can be provided for Federal
Express, UPS, and DHL.
<PRE><FONT SIZE="2" FACE="courier"></FONT>
<FONT SIZE="2" FACE="courier">  &lt;WIDL TEMPLATE="Shipping"&gt;</FONT>
<FONT SIZE="2" FACE="courier"></FONT>
<FONT SIZE="2" FACE="courier">    &lt;SERVICE NAME="packageTrack" ... /&gt;</FONT>
<FONT SIZE="2" FACE="courier">    &lt;SERVICE NAME="schedulePickup" ... /&gt;</FONT>
<FONT SIZE="2" FACE="courier"></FONT>
<FONT SIZE="2" FACE="courier">  ...</FONT>
</PRE>
<H3>
  4.2 <A NAME="timeouts">Service Timeouts</A>
</H3>
<P>
Service definitions support TIMEOUTS and RETRIES to handle situations when
a Web server is responding intermittently. If a service does not complete
within the specified number of seconds, it is tried again up to RETRIES times
after which it fails.
<PRE><FONT SIZE="2" FACE="courier"></FONT>
<FONT SIZE="2" FACE="courier">  &lt;SERVICE NAME="schedulePickup" METHOD="POST"</FONT>
<FONT SIZE="2" FACE="courier">           URL="http://www.fooShipping.com"</FONT>
<FONT SIZE="2" FACE="courier">           INPUT="pickupInput" OUTPUT="pickupOutput"</FONT>
<FONT SIZE="2" FACE="courier">           TIMEOUT="5" RETRIES="5" /&gt;</FONT>
<FONT SIZE="2" FACE="courier">   ...</FONT>
</PRE>
<H3>
  4.3 <A NAME="bindings">Bindings</A>
</H3>
<P>
'Input' and 'Output' bindings specify the input and output variables of a
particular service. Input bindings define the name-value pairs to be passed
via Get or Post methods to a Web-based application. Output bindings use object
references to identify and extract data elements from documents returned
by HTTP requests.
<PRE>
    &lt;BINDING NAME="TrackInput" TYPE="INPUT"&gt;
    ...
    &lt;BINDING NAME="TrackOutput" TYPE="OUTPUT"&gt;
    ...
</PRE>
<H3>
  4.4 <A NAME="formNames">Form Names</A>
</H3>
<P>
The FORMNAME attribute of a variable declaration enables the parameters of
a service to be re-named. This feature is useful for defining multiple
implementations of a service which require a common interface, yet must pass
the proper name-value pairs to individual Web-sites where the services are
hosted.
<PRE>
     &lt;BINDING NAME="TrackInput" TYPE="INPUT"&gt;
       &lt;VARIABLE NAME="TrackingNum" TYPE="String" FORMNAME="trk_num" /&gt;
    ...
</PRE>
<H3>
  4.5 <A NAME="headers">HTTP Headers</A>
</H3>
<P>
The values of variables declared as USAGE="Header" get passed as part of
an HTTP header and are not included in the name-value pairs submitted to
back-end services (i.e. CGI script) via Get or Post. Variable values may
also be hardcoded by providing a Value.
<PRE>
    &lt;BINDING NAME="anInput" TYPE="INPUT"&gt;
       &lt;VARIABLE NAME="REFERRER" TYPE="String" 
                  VALUE="http://www.company.com"  USAGE="HEADER" /&gt;
    ...
</PRE>
<H3>
  4.6 <A NAME="internalVariables">Internal Variables</A>
</H3>
<P>
The values of variables declared as USAGE="Internal" are accessible within
WIDL declarations and are not included in the name-value pairs submitted
to back-end services (i.e. CGI script) via Get or Post. In this example the
value an input variable 'state' is used to complete the URL for the service
'AutoLoan'. Internal variable enable URL directory structures to be interactively
'queried'.
<PRE>
    &lt;SERVICE NAME="AutoLoan" Method="Get" 
             URL="http://www.autoloan.com/%state%.html"
             INPUT="AutoLoanInput" OUTPUT="AutoLoanOutput" /&gt;

		
    &lt;BINDING NAME="AutoLoanInput" TYPE="INPUT"&gt;
       &lt;VARIABLE NAME="state" TYPE="String" USAGE="INTERNAL" /&gt;
    ...
</PRE>
<H3>
  4.7 <A NAME="regions">Regions</A>
</H3>
<P>
The REGION element defines an area of a document by specifying START and
END object references. Named regions permit the extraction of data elements
relative to other features of a document. Regions are addressed using object
references that begin with the region name.
<PRE>
    &lt;BINDING NAME="NewsOut" TYPE="OUTPUT"&gt;  
       &lt;REGION NAME="tops" START="doc.p[3]" END="doc.h[4]" /&gt;  
       &lt;VARIABLE NAME=stories TYPE="String[]" REFERENCE="tops.a[].text" /&gt;  
       &lt;VARIABLE NAME="links" TYPE="String[]" REFERENCE="tops.a[].href" /&gt; 
       ...
</PRE>
<H3>
  4.8 <A NAME="conditions">Conditions</A>
</H3>
<P>
Conditions define 'success' and 'failure' states for output bindings, and
determine whether a binding attempt should be retried in the case of a 'server
busy' error:
<PRE>
    &lt;BINDING NAME="AutoLoanOutput" TYPE="OUTPUT"&gt;  
       &lt;CONDITION TYPE="FAILURE" REASONTEXT="State not found" /&gt;
    ...  
</PRE>
<P>
<PRE>
    &lt;BINDING NAME="TrackOutput" TYPE="OUTPUT"&gt;
       &lt;CONDITION TYPE="SUCCESS" REFERENCE="doc.title[0].text" 
                  MATCH="Shipping Airbill:*" 
                  REASONREF="doc.p[1].value" /&gt;
    ...
</PRE>
<P>
<PRE>
    &lt;BINDING NAME="getPrice" TYPE="OUTPUT"&gt;
       &lt;CONDITION TYPE="RETRY" REFERENCE="doc.headings[0].text" 
                  MATCH="*Server Busy*" 
                  WAIT="5" RETRIES="4" /&gt;
    ...
</PRE>
<P>
Conditions can apply to a binding as a whole, or to a specific object reference.
Conditions can define error messages to be returned as the value of the service;
error messages can be a literal, or can be extracted from the returned document.
<P>
This mechanism can handle not only unexpected errors, but also can be used
to map application-level errors from the back-end program (i.e. responses
resulting from invalid or missing input values).
<P>
<H3>
  4.9 <A NAME="rebind">Multiple Bindings</A>
</H3>
<P>
Conditions can direct a service to attempt an alternate binding for the
extraction of output values:
<PRE>
    &lt;BINDING NAME="getPrice" TYPE="Output"&gt;  
       &lt;CONDITION TYPE="FAILURE" REBIND="shirtPrice" /&gt; 
    ...
    &lt;BINDING NAME="shirtPrice" TYPE="Output"&gt;  
    ...
</PRE>
<P>
Multiple bindings are useful in situations where the documents returned by
a back-end program are dependent upon the input criteria that was submitted
in the HTTP request. For example, a retail Web site may return a document
with a different structure for an SKU depending on whether the item requested
is a shirt, a tie, or trousers. The use of multiple bindings allows a condition
to determine the appropriate binding for extracting the desired data. Must
refer to a binding that is defined in the same WIDL interface.
<H3>
  4.10 <A NAME="serviceChains">Service Chains</A>
</H3>
<P>
Conditions can direct a service to initiate a service chain, in which case
the name-value pairs of an output binding are passed into a second service.
The name-value pairs must match the variable names in the input binding of
the second service for the service-chain to succeed.
<PRE>
    &lt;Binding Name="productSearchOutput" Type="Output"&gt;  
      &lt;Condition Type="Success" Service="ExtractPrices" /&gt;  
    ...
</PRE>
<P>
Service chains can be used with Web-based e-commerce systems when it is necessary
to invoke multiple services in sequence to complete a purchase.
<P>
  <HR>
<H2>
  5. <A NAME="Reference">WIDL Reference</A>
</H2>
<P>
The Web Interface Definition Language (WIDL) is an application of the eXtensible
Markup Language (XML); its definition consists of the various XML elements
defined in this section.
<H3>
  Major Elements
</H3>
<DL>
  <DD>
    <B>WIDL </B>- defines an interface
  <DD>
    <B>SERVICE </B>- child of WIDL - defines a service
  <DD>
    <B>BINDING </B>- child of WIDL - defines input and output parameters for
    services
</DL>
<H3>
  Minor Elements
</H3>
<DL>
  <DD>
    <B>VARIABLE </B>- child of BINDING - defines a variable within a binding
  <DD>
    <B>CONDITION </B>- child of BINDING - defines a condition within a binding
  <DD>
    <B>REGION </B>- child of BINDING - defines a area within a document
</DL>
<P>
The following sections define the elements of WIDL.
<H3>
  5.1 <A NAME="WIDL">WIDL Element</A>
</H3>
<P>
&lt;WIDL&gt; is the parent element for the Web Interface Definition Language;
it defines an interface. Interfaces are groupings of related services and
bindings. The following are attributes of the &lt;WIDL&gt; element:
<P>
<TABLE BORDERCOLOR="#000000" BORDER="1" WIDTH="600" CELLSPACING="4">
  <TR>
    <TD BGCOLOR="#C0C0C0"><B>Attribute</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Description</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Type</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>#</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Default</B></TD>
  </TR>
  <TR>
    <TD>NAME</TD>
    <TD>Establishes a name for an interface. The interface name is used in
      conjunction with a service name for naming or directory services.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>VERSION</TD>
    <TD>Identifies the version of WIDL.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>"2.0"</TD>
  </TR>
  <TR>
    <TD>TEMPLATE</TD>
    <TD>WIDL enables common interfaces to services provided by multiple vendors.
      A shipping template defines a functional interface for shipping services;
      various implementations can be provided for Federal Express, UPS, and DHL.</TD>
    <TD>URI</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>BASEURL</TD>
    <TD>BASEURL is similar to the &lt;BASE HREF=""&gt; statement in HTML. Some
      of the services within a given WIDL may be hosted from the same Base URL.
      If BASEURL is defined, the URL for various services can be defined relative
      to BASEURL. This feature is useful for replicated sites which can be addressed
      by changing only the BASEURL, instead of the URL for each service.</TD>
    <TD>URI</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>OBJMODEL</TD>
    <TD>Specifies an object model to be used for extracting data elements from
      HTML and XML documents. Object models are the result of parsing HTML or XML
      documents. The use of object models is central to the functionality of WIDL.
      Object References are used in &lt;VARIABLE/&gt;, &lt;CONDITION/&gt; and
      &lt;REGION/&gt; elements.</TD>
    <TD>String</TD>
    <TD>0&nbsp;or&nbsp;1</TD>
    <TD>wmdom</TD>
  </TR>
</TABLE>
<P>
<H3>
  5.2 <A NAME="SERVICE">Service Element</A>
</H3>
<P>
The &lt;SERVICE/&gt; element describes a request/response interaction with
a Web server. Web servers use Get and Post methods to return documents and
invoke CGI scripts and services via NSAPI, ISAPI, or other back-end Web server
programs. Web servers typically take a set of input parameters, perform some
processing, then return a static or dynamically generated HTML, XML or text
document.
<P>
The attributes of the &lt;SERVICE/&gt; element map an abstract service name
to an actual URL, specify the HTTP method to be used to access the service,
and designate 'bindings' for input and output parameters.
<P>
<TABLE BORDERCOLOR="#000000" BORDER="1" WIDTH="600" CELLSPACING="4">
  <TR>
    <TD BGCOLOR="#C0C0C0"><B>Attribute</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Description</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Type</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>#</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Default</B></TD>
  </TR>
  <TR>
    <TD>NAME</TD>
    <TD>Establishes a name for a service. The service name is used in conjunction
      with an interface name for naming or directory services</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>URL</TD>
    <TD>Specifies the Uniform Resource Locator (URL) for the target document.
      A service URL can be either a fully qualified URL or a partial URL that is
      relative to the BaseURL provided as an attribute of the &lt;WIDL&gt; element.</TD>
    <TD>URI</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>METHOD</TD>
    <TD>specifies the HTTP method ("Get" or "Post") to be used to access the
      service.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>"Get"</TD>
  </TR>
  <TR>
    <TD>INPUT</TD>
    <TD>Designates the &lt;Binding&gt; to be used to define the input parameters
      for programs that call the service. The specified name must be that of a
      &lt;BINDING&gt; contained within the same &lt;WIDL&gt; as the service.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>OUTPUT</TD>
    <TD>Designates the &lt;Binding&gt; to be used to define the output parameters
      for programs that call the service. The specified name must be that of a
      &lt;BINDING&gt; contained within the same &lt;WIDL&gt; as the service.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>AUTHUSER</TD>
    <TD>Establishes the Username to be submitted for HTTP Authentication.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>AUTHPASS</TD>
    <TD>Establishes the Password to be submitted for HTTP Authentication.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>TIMEOUT</TD>
    <TD>If the service does not complete within the specified number of seconds,
      it is tried again up to RETRIES times after which it fails.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>RETRIES</TD>
    <TD>Number of times to retry the service before failing.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
</TABLE>
<H3>
  5.3 <A NAME="BINDING">Binding Element</A>
</H3>
<P>
The &lt;BINDING&gt; element defines input and output variables for a service.
Input bindings describe the data submitted via Get or Post to a Web server;
for example, the input fields in an HTML form. Static HTML document do not
require input variables. Output bindings describe which data elements are
to be mapped from the output document and returned as a result of an HTTP
request to a Web server with the given input variables. In most cases an
output binding will map only a subset of the available data elements in the
output document.
<P>
<TABLE BORDERCOLOR="#000000" BORDER="1" WIDTH="600" CELLSPACING="4">
  <TR>
    <TD BGCOLOR="#C0C0C0"><B>Attribute</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Description</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Type</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>#</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Default</B></TD>
  </TR>
  <TR>
    <TD>NAME</TD>
    <TD>Establishes a name for a binding. The name is used in &lt;SERVICE/&gt;
      definitions and in &lt;CONDITION/&gt; statements that initiate service chains.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>TYPE</TD>
    <TD>Specifies whether a binding defines input or output variables.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>"Output"</TD>
  </TR>
</TABLE>
<H3>
  5.4 <A NAME="VARIABLE">Variable Element</A>
</H3>
<P>
The &lt;VARIABLE/&gt; element is used to describe both input and output binding
parameters. Different attributes are used depending on the type of parameter
being described.
<P>
<P>
<TABLE BORDERCOLOR="#000000" BORDER="1" WIDTH="600" CELLSPACING="4">
  <TR>
    <TD BGCOLOR="#C0C0C0"><B>Attribute Name</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Description</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Type</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>#</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Default</B></TD>
  </TR>
  <TR>
    <TD>NAME</TD>
    <TD>Identifies both the program variable and the VARIABLE definition itself.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>FORMNAME</TD>
    <TD><I>BINDING TYPE="Input":</I><BR>
      Specifies the variable name to be submitted via Get or Post methods. Obscure
      back-end variables can be given names that are more meaningful in the context
      of the service described by WIDL. Used in conjunction with WIDL Templates,
      FORMNAME permits the mapping of a single variable name across multiple service
      implementations.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>TYPE</TD>
    <TD>Specifies both the data type and dimension of the variable.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>USAGE</TD>
    <TD>The default usage of variables is for specification of input and output
      parameters. Variables can also be used internally within WIDL, as well as
      to pass header information in an HTTP request. For instance, using internal
      variables a portion of a service's URL or a pattern for matching within an
      object reference can be specified as a variable that is part of an input
      binding.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>Default</TD>
  </TR>
  <TR>
    <TD>VALUE</TD>
    <TD>Designates a value to be assigned to the variable in HTTP transactions.
      For input variables this has the effect of rendering the variable invisible
      to calling programs, i.e. the specified value is submitted to the Web server
      without requiring an input from calling programs. For output variables this
      has the effect of hard-coding the value returned when the service is invoked.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>REFERENCE</TD>
    <TD><I>BINDING TYPE="Output":</I><BR>
      Any valid object reference defined by the specified Object Model.
      <P>
      Identifies a property (typically the value) of an HTML document object to
      be assigned to the associated program output variable. If the identified
      object is not present in the output document, or the specified property is
      not valid for the object, null is assigned into the program output variable.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>NULLOK</TD>
    <TD><I>BINDING TYPE="Output":</I><BR>
      Overrides the implicit condition that all output variables return a non-null
      value.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>"False"</TD>
  </TR>
</TABLE>
<P>
<H3>
  5.5 <A NAME="CONDITION">Condition Element</A>
</H3>
<P>
The &lt;CONDITION/&gt; element is used in output bindings to specify success
and failure conditions for the binding of data to be returned to calling
programs. Conditions enable branching logic within service definitions; they
are used to attempt alternate bindings when initial bindings fail and to
initiate service chains, whereby the output variables from one service are
passed as name-value pairs into the input bindings of a second service.
Conditions also define error messages returned to calling programs when services
fail.
<P>
<TABLE BORDERCOLOR="#000000" BORDER="1" WIDTH="600" CELLSPACING="4">
  <TR>
    <TD BGCOLOR="#C0C0C0"><B>Attribute Name</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Description</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Type</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>#</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Default</B></TD>
  </TR>
  <TR>
    <TD>TYPE</TD>
    <TD>Specifies whether a condition is checking for the 'Success' or the 'Failure'
      of a binding attempt, or whether a binding attempt should be retried in the
      case of a 'server busy' error.
      <P>
      Any variable that returns a NULL value will cause the entire binding to fail,
      unless the NULLOK attribute of that variable has been set to true. Conditions
      can catch the success or failure of either a specific object reference or
      of an entire binding. In the case where a condition initiates a service chain,
      it is important that all variables bind properly.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>"Success"</TD>
  </TR>
  <TR>
    <TD>REFERENCE</TD>
    <TD>Specifies an object reference which extracts data from the HTML or XML
      document returned as the result of a service invocation. The Reference attribute
      for conditions is equivalent to the Reference attribute used in variable
      definitions.
      <P>
      Identifies the document object property that will be compared with the text
      pattern specified by the Match attribute.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>MATCH</TD>
    <TD>Specifies a text pattern that will be compared with the object property
      referenced by the Reference attribute.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>REBIND</TD>
    <TD>Specifies an alternate output binding. Typically a failure condition
      indicates that the document returned cannot be bound properly. Rebind redirects
      the binding attempt. The use of REBIND allows a conditions to determine the
      appropriate binding for extracting the desired data. Must refer to a binding
      that is defined in the same WIDL interface.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>SERVICE</TD>
    <TD>Specifies a service to invoke with the results of an output binding.
      Aside from the obvious benefit of chaining services to further automate the
      tasks that can be encapsulated for client programs, there are many cases
      when target documents can only be retrieved after visiting several Web pages
      in succession. In some instances cookies are issued by an entry page that
      must be visited prior to interacting with HTML forms; in others, URLs are
      dynamically generated from databases for specific user identities.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>REASONREF</TD>
    <TD>Reference to an object's attribute to be returned as an error message
      when a service fails.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>REASONTEXT</TD>
    <TD>The text to be returned as an error message when a service fails.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>WAIT</TD>
    <TD>Number of seconds to wait before re-trying retrieval of a document after
      a server has returned a 'service busy' error.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>RETRIES</TD>
    <TD>Number of times to retry the service before failing.</TD>
    <TD>String</TD>
    <TD>0 or 1</TD>
    <TD>&nbsp;</TD>
  </TR>
</TABLE>
<H3>
  5.6 <A NAME="REGION">REGION Element</A>
</H3>
<P>
The &lt;REGION/&gt; element is used in output bindings to define targeted
sub-regions of a document. Regions permit the extraction of data elements
relative to other features of a document. Regions are critical for poorly
designed documents where it is otherwise impossible to differentiate between
desired data elements (for instance story links on a news page) and elements
that also match the search criteria.
<P>
<TABLE BORDERCOLOR="#000000" BORDER="1" WIDTH="600" CELLSPACING="4">
  <TR>
    <TD BGCOLOR="#C0C0C0"><B>Attribute</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Description</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Type</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>#</B></TD>
    <TD BGCOLOR="#C0C0C0"><B>Default</B></TD>
  </TR>
  <TR>
    <TD>NAME</TD>
    <TD>Specifies the name for a region. This name can then be used as the root
      of an object reference.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>START</TD>
    <TD>An object reference that determines the beginning of a region.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
  <TR>
    <TD>END</TD>
    <TD>An object reference that determines the end of a region.</TD>
    <TD>String</TD>
    <TD>Exactly One</TD>
    <TD>&nbsp;</TD>
  </TR>
</TABLE>
<H2>
  6. <A NAME="conclusion">Conclusion</A>
</H2>
<P>
Web technology is strong on interactivity, but low on automation. Electronic
commerce on the Web is primarily driven manually via a browser. In order
to achieve business-to-business integration organizations have resorted to
proprietary protocols. The many-to-many nature of Web commerce demands a
standard for automated integration.
<P>
This proposal defines the infrastructure necessary for Web resources to be
described as functional interfaces that can be invoked directly from business
applications written in languages such as Java, C/C++, COBOL, and Visual
Basic. By capturing details such as input parameters, service URLs, and data
extraction methods for output parameters, WIDL enables automation of interactions
normally performed manually via a browser.
<P>
  <HR>
<H2>
  7. <A NAME="References">References</A>
</H2>
<P>
<UL>
  <LI>
    <A HREF="http://www.w3.org/pub/WWW/TR/WD-xml-961114.html">XML W3C Working
    Draft</A> by Tim Bray, Jean Paoli, C.M. Sperberg-McQueen
  <LI>
    <A HREF="WD-xml-link" W3MIRHREF="http://www.w3.org/TR/WD-xml-link">Extensible Markup Language (XML):
    Part2. Linking</A> by Tim Bray, Steve DeRose
  <LI>
    <A HREF="http://www.w3.org/MarkUp/DOM/">Document Object Model</A> W3C Working
    Group
  <LI>
    <A HREF="ftp://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.html">XML,
    Java, and the Future of the Web</A> by Jon Bosak
  <LI>
    <A HREF="http://webmethods.com/technology/automating.html">Automating the
    Web with WIDL</A> by Charles Allen
</UL>
<P>
  <HR>
<P>
<A NAME="WIDL DTD"></A>
<H2>
  Appendix A - The complete WIDL DTD
</H2>
<PRE>
&lt;!ELEMENT WIDL ( SERVICE | BINDING )* &gt; 
&lt;!ATTLIST WIDL 
     NAME       CDATA   #IMPLIED
     VERSION (1.0 | 2.0 | ...) "2.0"
     TEMPLATE   CDATA   #IMPLIED 
     BASEURL    CDATA   #IMPLIED  
     OBJMODEL (wmdom | ...) "wmdom" 
&gt; 

		
&lt;!ELEMENT SERVICE EMPTY&gt;  
&lt;!ATTLIST SERVICE 
     NAME       CDATA   #REQUIRED 
     URL        CDATA   #REQUIRED 
     METHOD (Get | Post) "Get" 
     INPUT      CDATA   #IMPLIED 
     OUTPUT     CDATA   #IMPLIED 
     AUTHUSER   CDATA   #IMPLIED 
     AUTHPASS   CDATA   #IMPLIED  
     TIMEOUT    CDATA   #IMPLIED 
     RETRIES    CDATA   #IMPLIED
&gt; 

		
&lt;!ELEMENT BINDING ( VARIABLE | CONDITION | REGION )* &gt;  
&lt;!ATTLIST BINDING 
     NAME       CDATA   #REQUIRED 
     TYPE (Input | Output) "Output"
&gt; 

		
&lt;!ELEMENT VARIABLE EMPTY&gt; 
&lt;!ATTLIST VARIABLE 
     NAME       CDATA   #REQUIRED 
     FORMNAME   CDATA   #IMPLIED 
     TYPE (String | String[] | String[][]) "String"
     USAGE (Default | Header | Internal) "Function" 
     REFERENCE  CDATA   #IMPLIED
     VALUE      CDATA   #IMPLIED 
     MASK       CDATA   #IMPLIED 
     NULLOK             #BOOLEAN
&gt; 

		
&lt;!ELEMENT CONDITION EMPTY&gt;  
&lt;!ATTLIST CONDITION 
     TYPE  (Success | Failure | Retry) "Success" 
     REF        CDATA   #REQUIRED 
     MATCH      CDATA   #REQUIRED
     REBIND     CDATA   #IMPLIED 
     SERVICE    CDATA   #IMPLIED 
     REASONREF  CDATA   #IMPLIED 
     REASONTEXT CDATA   #IMPLIED 
     WAIT       CDATA   #IMPLIED 
     RETRIES    CDATA   #IMPLIED
&gt; 

		
&lt;!ELEMENT REGION EMPTY&gt; 
&lt;!ATTLIST REGION 
     NAME       CDATA   #REQUIRED 
     START      CDATA   #REQUIRED
     END        CDATA   #REQUIRED
&gt; 
</PRE>
</BODY></HTML>

		
.

NEW PAGES:

[ODDNUGGET]

[GOPHER]