
Page 5
CWA 14050-8:2000
1. Introduction
1.1 Background to Release 3.0
The CEN XFS Workshop is a continuation of the Banking Solution Vendors Council workshop and maintains a
technical commitment to the Win 32 API. However, the XFS Workshop has extended the franchise of multi
vendor software by encouraging the participation of both banks and vendors to take part in the deliberations of
the creation of an industry standard. This move towards opening the participation beyond the BSVC's original
membership has been very succesful with a current membership level of more than 20 companies.
The fundamental aims of the XFS Workshop are to promote a clear and unambiguous specification for both
service providers and application developers. This has been achieved to date by sub groups working
electronically and quarterly meetings.
The move from an XFS 2.0 specification to a 3.0 specification has been prompted by a series of factors. Initially,
there has been a technical imperative to extend the scope of the existing specification of the XFS Manager to
include new devices, such as the Card Embossing Unit.
Similarly, there has also been pressure, through implementation experience and the advance of the Microsoft
technology, to extend the functionality and capabilities of the existing devices covered by the specification.
Finally, it is also clear that our customers and the market are asking for an update to a specification, which is
now over 2 years old. Increasing market acceptance and the need to meet this demand is driving the Workshop
towards this release.
The clear direction of the XFS Workshop, therefore, is the delivery of a new Release 3.0 specification based on
a C API. It will be delivered with the promise of the protection of technical investment for existing applications
and the design to safeguard future developments.
1.2 XFS Service-Specific Programming
The service classes are defined by their service-specific commands and the associated data structures, error
codes, messages, etc. These commands are used to request functions that are specific to one or more classes of
service providers, but not all of them, and therefore are not included in the common API for basic or
administration functions.
When a service-specific command is common among two or more classes of service providers, the syntax of the
command is as similar as possible across all services, since a major objective of the Extensions for Financial
Services is to standardize command codes and structures for the broadest variety of services. For example, using
the
WFSExecute
function, the commands to read data from various services are as similar as possible to each
other in their syntax and data structures.
In general, the specific command set for a service class is defined as the union of the sets of specific capabilities
likely to be provided by the developers of the services of that class; thus any particular device will normally
support only a subset of the command set defined for the class.
There are three cases in which a service provider may receive a service-specific command that it does not
support:
The requested capability is defined for the class of service providers by the XFS specification, the particular
vendor implementation of that service does not support it, and the unsupported capability is
not
considered
to be fundamental to the service. In this case, the service provider returns a successful completion, but does
no operation. An example would be a request from an application to turn on a control indicator on a
passbook printer; the service provider recognizes the command, but since the passbook printer it is
managing does not include that indicator, the service provider does no operation and returns a successful
completion to the application.