Abstract
Governments around the globe are looking for the right solutions for interopera-bility. To Danish Government the Universal Business language (UBL) has be-come the solution for e-commerce integration between a Public Procurement Por-tal and government Enterprise Resource Planning (ERP) systems. Danish Gov-ernment has adopted an early version of UBL as part of a nationwide cross-governmental XML strategy. UBL is developed by the Organization for the Ad-vancement of Structured Information Standards (OASIS). The reasoning behind the choice of UBL is that UBL will do the job and that it may very well be the strongest contender for a future international and open standard. The Danish XML project has also adopted other elements of UBL as strategic elements such as Naming and Design Rules and Core Components.
Keywords
Table of Contents
Interoperability is one of the major issues for e-government. Is the use of XML the basic technology to achieve the goals of interoperability? Today most will probably agree because there is a general consensus of the importance of XML. Here, however, all clarity ends.
The problem everybody is facing is: Which XML languages do we choose? Do we create our own languages? How do we create them? Do we adopt languages developed by others? How do we decide which to adopt? How do we make them coherent across domains?
Denmark has not come up with all the answers to these difficult - not to say im-possible to answer - questions, but have gathered some important experience in working with XML for e-Government on a large scale.
The Danish XML Project is an integral part of the national e-government project and part of the national Enterprise Architecture for e-Government work. These projects cover all tiers of government in Denmark. Various boards and commit-tees govern these major projects, which all include representatives from state, counties and municipalities.
The basic concepts behind the XML project are coherence, cooperation and re-use. A common framework and methodology are the main ingredients in this paradigm - called the OIOXML paradigm (OIO stands for Open public Informa-tion Online). The framework and methodology includes:
A governance set-up related to both the Government's IT-policy and po-litical agreements among the state, counties and municipalities. Basically the Danish approach is based on voluntary adoption of this paradigm. What makes it work is the fact that everything is done in open, consen-sus-oriented processes. Business needs and policy requirements are the key drivers, not technology. Moreover, as this project is a strategic part of painting the full e-government picture, nobody wants to go against it without good reason.
A coordinated organizational set-up with the Coordinating Information Committee and the XML Committee as central focal points supported by a number of domain committees covering various sectors as well as spe-cialized workgroups. The Danish XML Committee foresees the develop-ment of XML standards in the Danish public sector.
A modeling approach that emphasizes fine granularity. This means that focus is on information objects rather than messages. This enables reuse by developing building blocks in the form of core types, which can be combined to build composite schemas. These can again be combined to build messages and interfaces.
XML Schema Naming and Design Rules (NDR) based on international best practice and especially the UBL NDR. Some minor, but important issues, have been simplified in the Danish NDR. Approved schemas de-veloped according to the Danish NDR are also called OIOXML schemas.
As Denmark is a small country and has limited resources adoption of in-ternational XML-vocabularies and standards is a natural part of its work strategy. This means that international XML vocabularies may be adopted even though they do not conform to all naming and design rules. This is a natural part of a pragmatic way of working. In fact the NDR states that OIOXML is developed in English rather than in Danish. This is to make international cooperation and import/export of XML-vocabularies easier and to enforce competition in relation to development of solutions on an international scale.
Classification of national e-government standardized XML schemas. OIOXML is divided into three main classes.
Core components - which must be reused by all and across do-mains. E.g. the definition of a person
Domain components - which must be reused within relevant do-mains. E.g. the definition of a patient (health domain)
NDR components - which comply with the Naming and Design Rules, but are not suitable for reuse (e.g. a schema for a specific interface to a local system).
A standardization process which includes consultation of stake holders and domain experts, public hearings and other procedures such as submit-ting a CV (Curriculum Vitae) for the submitted schema, which describes the context, the content and the development process.
Tools to support the development and sharing of XML schemas and other documents. The most important tool is the InfoStructureBase, which in-cludes an open registry / repository for XML schemas and yellow pages for web services in the form of an UDDI (Universal Description and Dis-covery and Integration for web services). Other examples are tools for checking conformance, validation of XML schemas and XML Schema resolver/splitter (for rearranging the physical structure without changing the logical structure).
A number of central initiatives governed by the XML committee and secretariat form the base of the OIOXML schema family. This spans the range from generic building blocks like name and address to generic document types like letters, notes and agendas and a number of other business documents.
The development of most OIOXML, however, is driven by other national or local projects. This means that most schemas are developed as part of projects that need the schemas for actual implementation at a date specified in a project plan. This does not make the whole development process easier, but has so far been managed successfully due to a combination of pragmatism, dialogue and good-will from all parties involved.
One example of this pragmatic approach is the adoption of an early version of UBL in relation to a major strategic e-procurement project.
The Danish Public Procurement Portal (DOIP) is an electronic market place to which both private and public purchasers and their suppliers have access, and whose functionality, interface, security and transaction costs are regulated by the public sector. It was the first public procurement portal in Europe, and the general aim is to lead the way by establishing standards for e-commerce in both Denmark and EU. The establishment of the Public Procurement Portal is an im-portant part of the strategy to make procurement efficient and is implemented on the basis of the wish to create a common infrastructure for the trade between the public units and the suppliers.
Having a public sector procurement of goods and services at approximately DKK100 billion per year, even modest improvements in efficiency will be of great value for the Danish society. By virtue of the public sector's purchasing volume, increased use of e-commerce will furthermore contribute to the penetra-tion of e-commerce in Denmark in general. The suppliers will get accustomed to e-commerce and an infrastructure will be established. Particularly favorable ar-rangements have been made to secure access by small suppliers.
The portal, however, did not initially have the expected impact, because the Por-tal did not support internal procurement processes in the authorities . Data from invoices and orders was still registered and handled manually. As a result, the Agency for Governmental Management wanted an ERP integrated module to be used on the intranets of the various authorities. This system supports the pro-curement processes with the different roles and certificates and initiates the syn-chronization of data to the economy system Navision Attain in a local govern-ment version called Navision Stat, which is used across all central government authorities.
The new module is envisaged as a supplement to Navision Stat. The module is used for handling the most frequent commerce, while Navision Stat is used for handling the more special cases by allowing them to be processed manually. The goal is that the main part of government procurement is processed through the new module.
Main advantages include faster and more streamlined processes, pure online pro-curement, reduced administrative costs, improved overview and cheaper pro-curement due to competition and discounts.
Since the goal was a roll-out to all Government institutions and their suppliers, it was decided that the system should be built on open standards and to let it inte-grate into the economic systems of the institutions and suppliers. The question was then which XML-based language to choose.
The Agency for Governmental Management contacted the XML Committee and cooperation with the e-commerce subcommittee (e-commerce SC) was estab-lished.
This quickly led to the decision to look closer into ebXML - the electronic busi-ness XML framework developed by the UN - and particularly UBL, which is de-veloped within this framework. After some initial research the subcommittee de-cided to base the work on UBL. From then on it has worked at creating a Danish context for UBL. In this work several proposals for enhancements to UBL have been submitted to the OASIS UBL Technical Committee and this experience has been very positive. At the time when the final decision had to be made, UBL was still under development. The current version at the time was 0.7 and that version was chosen with full awareness that it would evolve further. In order to support the needs of the integration project some additional elements had to be added lo-cally to 0.7, elements which have since been adopted in later versions of UBL. The schemas went through a public hearing in late 2003 and was officially adopted in early 2004.
In December 2003 a new law made it possible to require that a supplier send electronic invoices. The opposite, that government institutions shall be able of receiving these electronic invoices, is naturally also a requirement. This is ex-pected to substantially increase the volume of transactions in the system. Later, when UBL has finally been developed to a version 1.0, the work in the Danish context will follow and a migration plan from UBL 0.7 will be produced.
Even though UBL only defines less than 10 messages it is quite extensive and therefore hard to get an overview of. Some of the complexity is the result of the relations between the different messages. Another is that it is built on ebXML, which is a framework in itself. Thirdly, it has several representations with spreadsheet as a base, with alternatives in W3C XML Schema and UML.
The NDR for UBL and the work that has been put into it has been a great inspira-tion for the work on the Danish NDR. The Danish viewpoint is that NDR-work is very important in itself and that is also is very important to align the work done in different countries to ensure interoperability. Fortunately most work is based on ebXML's Core Components and its naming rules, which form a common ground.
The main difference between the way UBL and Denmark uses XML Schema is that UBL is based heavily on the derivation mechanisms of W3C XML Schema , by extension and restriction. These are often called Object Oriented features. In OIOXML usage is paramount and the XML Schemas are to be used as messages in Web Services and to be reflected in general data models and databases during revision and new developments. Therefore, derivation based on complex types is not recommended. The reason is twofold: firstly it induces unnecessary complex-ity and secondly the lack of type-aware tools makes it premature and non-operational. In Denmark, using composition is recommended because it's simple and well supported.
The Danish XML project in currently working on a revision of the XML schema Naming and Design Rules and on implementation of the new classes of OIOXML. At the same time focus is also moving from the more syntax oriented focus of the NDR to the much more difficult focus on semantics. The means that getting the relevant authorities organized in domain committees has become a new focus area for the architecture and the XML project.
By making domain committees we not only intend to strengthen the level of ac-tivity, coordination and reuse within the domains, but also to provide a model for cross-domain coordination and reuse. And most of all - to make everybody take their share of responsibility of what is - at the end of the day e common project-goal : Interoperability with a long term perspective and high value.
The Danish experience shows that a national XML strategy is both necessary and possible even though the challenges are big. Adoption of international standards are also necessary, however, it is a challenge that standards are often non-existent or not quite ready and stable. Still choices have to be made in order to support real projects and real business. The cooperation with the OASIS UBL committee has been fruitful for the Danish Government and UBL is now providing important inputs to the national XML project. At the same time, the Danish XML project shares its bleeding-edge experiences with other countries as well as the private sector through use of open methods and by doing a lot of the work in the English language.
Open public Information Online
In Practice - several Business Cases where XML has been an enabler
e-Procurement/Denmark: Successful public/private procurement initiative in Denmark
http://europa.eu.int/ISPO/ida/jsps/index.jsp?fuseAction=showDocument&parent=whatsnew&documentID=693
The Public Procurement Portal
http://www.doip.dk/default.asp?lg=UK
OASIS UBL Technical Committee
http://www.oasis-open.org/committees/ubl
Send snail mail to
The National IT and Telecom Agency
Holsteinsgade 63
DK-2100 Copenhagen O
DENMARK
  |
Design & Development by deepX Ltd. |
