The role of standards in application development   Table of contents   Indexes   Standards and eCommerce: travel on the Web
 

Standards based software development & services

 Mikula, Norbert H. 
 
 Norbert H.  Mikula
 Chief Technology Officer
  Bellevue 
 DataChannel 
 USA 
 Washington 
DataChannel,  Chief Technical Officer,  OASIS,  600 108th Ave NE
Suite 900
Bellevue  Washington  98007 USA
Phone: +1 425 462 1999 email: norbert@datachannel.com web site: www.datachannel.com
 Biography
 Norbert Mikula - Mikula is responsible for directing DataChannel's efforts in the XML standards bodies as well as further advancing DataChannel's leadership in the arena of XML and Enterprise Information Portals. He developed one of the first XML parsers (NXP) and has been engaged in XML-related efforts since the early days of this standard. Currently, Mikula also serves as Chief Technical Officer on the board of directors of OASIS - the Organization for the Advancement of Structured Information Standards. He is a member of the XML.org Steering Committee and he represents his company at the ebXML initiative. He is the author of numerous whitepapers and articles and has been a speaker and track-chair at a variety of national and international conferences and industry events. Mikula holds a "Diplom Ingenieur" degree in Applied Computer Science from the University of Klagenfurt, Austria.
 

About DataChannel

 DataChannel was incorporated in 1996. At the time of this writing it employs about 180 people and it is still growing. While originally a purely software-oriented company, it had to realize very early on that the world is not a shrink-wrap one and that to solve customer problems, one has to augment software with Professional Services staff which can successfully install and deploy solutions, based not only on in-house products, but in combination with third party software and custom code development.
 This understanding ultimately lead to a merger with one of the leading Professional Services firm of our industry - Isogen. Isogen brought to DataChannel their very unique talent and philosophy of solving customer problems by using international standards, including ISO, W3C, IETF and OASIS.
 DataChannel was one of the first companies to make the strategic decision to use XML - and related standards - to build better software and to solve customer problems. The experiences of our endeavour is what I want to address over the course of the next few sections.
 

Standards based software development

 The current shipping version of DataChannel's core product - the DataChannel Server 4.0 - is an XML-based Enterprise Portal. A lot of work on the architectural level went into making sure that wherever possible and sensible, open standards should be used rather than proprietary inventions (our own or somebody else's).
 

Going beyond standards

 While architecting the DataChannel server 4.0, we knew we needed a high performance parser and stylesheet engine to drive the core of our product. At that time, we could not find any parser available which would satisfy our requirements with regards to speed and platform (Java). Thus, we decided to build a parser and stylesheet engine ourselves. We engaged in a co-development relationship with Microsoft to implement a Java-based counterpart to their XML and XSL engine.
 Developing a full-blown XML/XSL combo is a great learning experience. It also has the advantage of giving us the opportunity to do certain optimization necessary for the product right at the source level. However, it turns out to be an enormous resource drain as well. While it was the right thing for us to do when we started the project we finally decided that we will let tools-vendors take care of tools.
 Lesson learned : Unless you are in the tools business, don't develop tools. Standardized interfaces to required components provide easy integration and interchangeability of components.
 While conformance to standards has always been a target for us, sometimes we had to go beyond what a particular specification prescribed. The reason for that was usually the requirements of both our developers which already were working on our server product as well as general desiderata from outside sources. Sometimes it was convenience functions, sometimes additions in feature and functionality required by the product development team.
 Lesson learned : As a development company sometimes you are tempted/required to go beyond standards.
 For instance, we implemented the XML Data Reduced (XDR) specification, a first attempt at providing a next generation schema language. While this was not a W3C standard we felt it was worthwhile to present to our customers a technology outlook and enable early experimentation.
 Lesson learned : Make sure to a.) mark clearly where you go beyond standards and don't create the impression it is a standard and b.) prepare both internal and external customers that certain code changes and updates may be necessary if they want to move towards pure standards conformance.
 

Working with pre-standard specifications

 Already in the release 3.2 of our server, one could return the relevant portal metadata in XML format and apply XSL based stylesheets to create output from that. However, then it was still a special case and not the bases for the product. For the release 4.0 the decision was made to make XML based content/metacontent the norm and to use XSL to create the user interface.
 We were developing the XSL components when XSL itself was still very much in fluctuation. Constant changes in the target specification made it very hard to always catch up with the latest specification and to keep both internal users and customers happy. Naturally you end up with a situation in which some forces, trying to slow down the speed in which you introduce new features and functionality (which are often not compatible with the existing code-base), start to compete with those who want conformance to the latest draft at the moment a specification is out.
 When product development started, XSL was still far away from standardization but we had to move forward and start our implementation, based on a draft version, regardless. The only other option would have been to fall back on some proprietary approach and possibly end up re-inventing the wheel.
 Our next product release will be based upon the Apache.org XML parser and XSL stylesheet engine (Xerces and Xalan) which are based on XSL-T. Now, of course, non of the stylesheets developed for the old XSL is useful anymore. Almost all the stylesheets have to be re-done in order to support XSL-T.
 The DataChannel server uses the DOM - the Document Object Model - to provide an abstraction layer between the actual datasource the product works with and the application code a developer works with. Our experience with the DOM is pretty much the same as with XML and XSL.
 Lesson learned : Be willing to pay the price as an early implementor.
 

It can really pay off ...

 While reading the preceding paragraphs can show you how hard the life of an early technology adaptor is, I hope the next paragraphs will be able to shed a slightly different light on the subject matter.
 

WebDAV experience

 Collaborative work on document across the Internet is one of the big features of an Enterprise Information Portal. Instead of developing our own approach and protocol, we made the decision to re-use existing research in that area.
 WebDAV - The Web Distributed Authoring and Versioning Protocol deemed to be the right tool for the job. In the case of WebDAV we were lucky, IBM already offered a WebDAV module (DAV4J) which turned out to be very suitable for our implementation. Integration into our own modules turned out to be fairly straight-forward and we certainly saved enormous time by not having to invent and implement it ourselves.
 Lesson learned : Reduce development time by licensing commodity functionality for certain standards
 One of the most important features of an Enterprise Information Portal is that it allows our users to manage access controls lists to data resources. In other words, who is allowed to see what. Developing a model for the management of these permission can be tedious and is error prone. Instead, by following the approach of an existing standard, such as WebDAV, we could rely on the wisdom of numerous very intelligent people who have spend many months to think through all the complexity of the problem at hand.
 Lesson learned : Standards contain huge amounts of intellectual property which can be reused.
 Today we are in the fortunate situation that a number of software vendors do already provide solutions that offer WebDAV compliant interfaces. Some examples:
 Microsoft Office 2000 : This popular suite of office productivity software is WebDAV compliant. Thus, one can directly save from within, say Word, to our WebDAV compliant server.
 Microsoft Internet Explorer 5.0 : Webfolders use WebDAV to communicate with a server application. This makes Webfolders a client application which allows you to navigate and operate a portal.
 Other solutions such as Excosoft's editor have not been tested for integration but should plug into this solutions package just as well all other WebDAV-enabled solutions. Granted, interoperability is not yet 100% across all WebDAV implementations, but things are progressing.
 Lesson learned : Open standards enable (almost) free integration points for third party software.
 

Content re-use

 One of the best advertised reasons for using XML is : Separation of content from display. While this is XML 101, it deserves a special mention here, as all too often people only mean data and documents when they speak about this. Our decision to separate content from display (from programming logic) in our software itself paid off big time.
 Not only does this give us 100% control over the look and feel of our user interface, but it also allows us to deliver content to devices we did not even anticipate when we started developing the architecture of the product. While certainly non browser-based devices were always on our radar screen, we did not specifically plan for them. However, as we saw the emergence of the market for wireless devices, it was easy for us to develop stylesheets to convert the content of our user interfaces to WML and HDML as opposed to only fancy (d)HTML.
 Lesson learned : Separation of content from display not only works for data and documents but also for user interfaces.
 

Even more payoff in the future

 Adherence to standards requires often a higher investment upfront whereas the returns on this investment only become visible over time. I believe we have only seen some of the benefits of standards compliance so far.
 

Registries and repositories

 When developing Enterprise Information Portals, we don't always know beforehand what schema is being used for XML information inside a company or between companies. It is also very hard to anticipate what schemas will be predominant a year after a customer purchased our product. How can you know what stylesheets you need to develop ?
 As long as the schema is a cross-industry and standardized one, we likely will also see standardized stylesheets for such schemas. These stylesheets can also be stored in a registry and repository and retrieved as a "default" style in case no specific in-house stylesheet is present.
 

Standards and Professional Service

 Software development using open standards is only part of DataChannel's business. Also our Professional Services group, especially them, are experts in using non-proprietary approaches to solving customer problems.
 

ISO vs. W3C ?

 While for a long time there seemed to be a chasm between the "old school" of ISO/ANSI/IEC-driven standards, such as SGML, DSSSL, HyTime and Topic Maps, and "new age" W3C and IETF-driven standards such XML, XSL, HTML and WebDAV, we have come to the conclusion that this is a silly idea.
 In reality many customers prefer the usage of ISO controlled standards as they expect longevity and stability. ISO standards also come with the promise of being less prone to be influenced by one single vendor or small group of vendors. Sometimes corporate policies dictate the use of ISO approaches. Also, as many of you may well be aware of, lots of our current XML standards draw heavily from ISO ideas, often applying the general 80/20 rules and adding ease of use and ease of implementation considerations. Still, some of the concepts found there are very necessary to solve hard and complex customer problems and are well proven approaches.
 As web-technologies start to be combined with document/content management solutions we also see more and more connection points between the typically heavy-lifting oriented ISO based solutions and their Web delivery counterparts. Integrating those two is less of a problem than it often appears.
 Lesson learned : "Old" school ISO and "new school" W3C go well together
 

Cost related

 The use of standards reduce your overall systems costs. One of the typical tasks of our professional services group is to integrate systems of various vendors into an overall architecture which solves a particular customer problem. A standards-based approach has proven to be a big cost-saving factor. Imagine an - all to common - scenario in which systems without any standards-based interfaces and data formats have to be connected. Mappings between different document types become necessary, the development of which can be costly and often hard to maintain.
 Similar to the way the standardization of components like screws and bolts fueled the industrial revolution, bringing down the costs of complex machinery and enabling engineers to focus on more solution-oriented aspects, it will have the same benefits for our information revolution.
 Lesson learned : Use of standards helps customers save money.
 

Vendor dependency

 Being exposed to proprietary data formats, one inevitably gets more and more locked into the solutions of a particular vendor and that in turn limits a free choice of application software and ultimately lets the vendor dictate the price and introduces unnecessary risks to the system (what if the vendor ceases to exist?).
 Lesson learned : Proprietary approaches put the longetivity of your system at risk.
 

Implementing the backbone

 DataChannel, as well as many other vendors and organizations, is trying to convince the IT community of today, that XML is the only way to manage information across the enterprise and between enterprises. We, DataChannel, suggest it in a form called the "XML backbone". It is the vision of the XML backbone to provide a unified abstraction layer across all the systems of a company. A crucial element in this puzzle is providing connectors to the legacy systems which export (or even better, export and import) XML based data. Whereas some of the connectors we build ourselves, we also have established various partnerships to get others. However, at the end of the day, this is a problem which only the entire vendor community can solve in an orchestrated fashion. We need to work together to identify common schemes for integrating legacy systems into XML in a standardized, uniform fashion.
 We demand : Open standards-based XML connectivity for all (legacy) data sources.
 Almost every single industry vertical has already started to work on schemas, trying to address the particular requriements of their environment. However, all the often we see more than one group of people creating multiple schemas which are sometimes overlapping, sometimes contradict each other. For our customers this creates a very uncertain environment and may even delay XML related projects, because of the fear of customers that they may be left with schemas which nobody really supports in the long run.
 We demand : Schema developing parties need to work together towards convergence not only in their own industry but also across industries.
 

Summary

 Working with standards, from the perspective of a vendor is sometimes hard and costly, however, it ultimately pays off - for yourself as well as your customer.
The role of standards in application development   Table of contents   Indexes   Standards and eCommerce: travel on the Web