Intellor.com: Software AG is taking a pre-eminent role in the XML
world, both in terms of new product direction, and actively contributing
to, and driving standards definition. Give us an overview of Software
AG's XML initiatives, in terms of products, proposals being submitted
for approval with the W3C and who the contributing Software AG
representatives are. Go into as much detail as you like.
Mike Champion: Software AG released the first native XML database
management system, Tamino, in late 1999. Since then, XML has become
pervasive throughout our product line. A good example is our middleware
system, EntireX, which has become XML-enabled with SOAP-like (and soon
SOAP 1.1) interfaces. Our Bolero application development system has been
integrated with Tamino and other XML tools. On the standards front, we
participate in the W3C Document Object Model, XML protocols, and XML
Schema activities; we have been VERY actively involved in shaping the
XML Query Language via our colleague Jonathan Robie, and we recently
hired the well-known XSLT author/implementer Michael Kay who represents
us on the XSL working group.
Intellor.com: As a company that is making substantial strategic
investments in XML do you ever get concerned that the hype in the press
around XML, and the sheer volume and complexity of new XML standards
sometimes strains credibility and comprehension, and may damage XML's
rate of adoption if expectations are not met.
Mike Champion: Yes, we do, to be perfectly honest. We always expected
XML to follow the pattern of Java, that is, the adoption curve described
by the Gartner Group's "hype cycle" (a rapid rise to a
"Peak of Inflated Expectations", followed by a decline to a
"Trough of Disillusionment", followed by a gradual rise to a
"Plateau of Productivity"). Java has survived the initial hype
that it would "destroy Windows" and the resulting plunge in
its visibility when it became clear that this would not happen; it now
enjoys a solid position as a productive technology. XML is probably just
past the "peak of inflated expectations"; we've seen XML used
to justify some extremely visionary scenarios presented by prominent
software executives, and now the reality that XML is basically a way of
describing data in a simple, interoperable way is becoming more obvious.
We firmly believe that the elegant simplicity at the core of the XML
technology family will continue to provide a solid foundation for
interoperable, device-independent, easy-to-build software systems - in
other words, XML will be a near-universal foundation for enterprise
software, but not some "sexy" technology that will solve many
problems in and of itself.
As for the complexity of the XML technologies themselves, that is a
subject of considerable discussion within the entire XML community. I'm
probably best known in the XML community as a minimalist who advocates
keeping the XML specs as small and as rooted in actual practice as
possible. We firmly believe in the principle that the real costs and
benefits of the various specs in the real world will determine their
ultimate evolution and viability. That's why we have taken the strategy
of: · implementing the "core" specs to the best of our
ability, · partnering with companies who can provide specialized tools
for using the more complex and obscure ones, · sounding out the real
needs of our customers rather than adopting the "buzzword du
jour" to guide implementation decisions.
Intellor.com: The XQuery proposal is certainly getting a lot of
close, critical, scrutiny and support in the various XML developer
discussion forums. How is Software AG positioned to deliver XQuery
conformant product to market, if this proposal is accepted?
Mike Champion: There is little dispute that the functionality XQuery
offers is critical, especially the ability to offer our users a tool
that allows the sorts of capabilities that SQL offers RDBMS users. We
already have a number of researchers and developers closely tracking and
implementing the drafts of XQuery. Whatever the form of the ultimate W3C
Recommendation, we are sure to quickly support it. We are well covered
on both sides of the "XSLT vs XQuery" debate, and are firmly
committed to support both with first-class implementations integrated
deeply into our products.
Intellor.com: Is XQuery destined to become SQL for the new
millennium, and what will its relationship to SQL be?
Mike Champion: That is a very interesting situation. There is an
activity in the SQL community (called SQLX) to standardize the XML
extensions offered by the various RDBMS vendors, and we participate in
that. We expect XQuery to become the de-facto standard for XML databases
for the next few years, if not the millennium. The RDBMS vendors
participate actively in both XQuery and SQLX, and we don't really know
what to expect when it comes to them actually shipping products. Will
XQuery displace SQL in the RDBMS world? We doubt it very much. Will
Object-Relational databases continue to be distinct from XML databases?
Will the world allow two similar but distinct query languages, one that
is RDBMS-centric with XML extensions and one that is XML-centric with
RDBMS-friendly extensions, to survive and prosper? We can only
speculate. What we do know is that the world needs a query language that
meets the requirements that XQuery has set out to meet, and XQuery
itself is best positioned to fill that need in the short run. In the
long run, perhaps something more rooted in SQL will evolve to fill that
need and the needs of RDBMS users; that will depend on whether the
Object-Relational vendors support XQuery in their XML-enabled products
or promote some alternative.
Intellor.com: What are your thoughts on the effect that XML query
languages are going to have on blurring the distinction between
accessing structured data and accessing unstructured data, or do you
think that XML adoption itself will already blur this distinction
anyway.
Mike Champion: I believe that there will be a synergy between XML
adoption and XML query languages. The more XML there is out on the Web,
the more useful it will be to have an XML query language; and the more
powerful the search tools for finding XML content in a way that exploits
its structure, the more XML will be stored on the Web. A reasonably
standard SQL language helped take RDBMS systems out of the lab and into
the corporations, and I suspect that a standard XML query language with
similar power will help promote the XML encoding of unstructured data.
Intellor.com: The software industry sometimes appears to have a
lot in common with the fashion industry. Technology development is
cyclical, with mature ideas showing up again in new guises. It would
seem that storage of XML data is better suited to hierarchical or OO
databases than relational. What are your thoughts on the challenges that
RDBMS vendors face in adapting relational structures to accommodate XML
data?
Mike Champion: First the "relational model" is a logical
view of data, not a physical data structure. I have no particular
knowledge of the actual data structures used in commercial RDBMS
systems, but I doubt if they are physically organized as rows and
columns with atomic values in the cells. The RDBMS vendors have faced a
challenge from the object databases over the last 5-10 years, and have
evolved into Object-Relational databases to some extent. Oracle has
moved away from the "pure" relational model to support
repeating groups (cells with array rather than atomic values) in its
version 8 a few years ago, so is now "post-relational". (Our
Adabas database had this feature decades ago, and was labeled
"pre-relational" for this then-unfashionable bit of
capability!) Oracle claims to have an XML data type (trees rather than
flat arrays?) in its version 9i, which would appear to validate our
"native XML" data storage model. So, I guess this confirms
your point about the cyclical nature of fashion in the database
industry! I have little doubt that the RDBMS vendors can bolt-on a
capability to handle XML data, but I suspect that databases that have
XML capability designed-in rather than bolted-on will continue to be
able to do more with less … less money, less footprint, less trouble,
etc.
Intellor.com: Are there any vertical markets that you concentrate
on with Tamino and any tools or enhancements available that support
these vertical applications?
Mike Champion: As a technology company, Software AG has traditionally
focused on the development of products that span the entire gamut of
industry requirements, without targeting any single vertical industry.
We do, however, partner with ISVs in numerous industries to further the
development of solutions for vertical markets. There are a host of
vertical/horizontal markets for which Tamino is particularly suitable.
These include, for example, media, healthcare, financial services,
supply chain management, mobile computing, portals, document management
and logistics.
Intellor.com: What made you choose these verticals?
Mike Champion: As a company that prides itself on our understanding
of XML, we've had to get involved to some extent to learn how these
vertical market specs relate to the infrastructure specs and to our
products. Our interest in healthcare, for example, is driven mostly by
the reality that the 1990's RDBMS and EDI technologies are simply
inadequate to address that industry's needs in an effective way. The
ingredients that XML adds to the mix - more efficient supply chain
integration, or wireless-enablement, for example - are
"gravy," if you will. In healthcare, on the other hand, I
almost NEVER hear of anyone who is satisfied with their RDBMS-based
systems; they are highly challenged to fit the semi-structured
healthcare text/data combination into their operations in an effective
way, and they desperately need data integration between organizations.
Likewise, most healthcare professionals don't spend their working day
sitting at a desk with a PC on it, so the only way for IT departments to
directly capture data is via mobile devices. In other words, the
benefits offered by XML are "meat and potatoes", not gravy.
Thus, our XML story - with Tamino to provide effective data management,
EntireX to XML-enable legacy systems - has immense potential for the
healthcare industry.
Intellor.com: Thank you for your time and sharing your thoughts
with us. Are there any ideas, comments, or predictions for the future,
you want to leave us with?
Mike Champion: A couple of things … First, I'm not worried about
the XML "hype meltdown". Just as the .com meltdown removed a
lot of impractical ideas from the "meme pool", a period of XML
disillusionment might help us all focus on the practical, real-world
benefits of XML today and build interoperable tools to support it. Peter
Chen said at a recent XML conference, "It takes 10 minutes to
understand (base) XML, and then 10 months to understand the new
technologies hung around it."
I think this perception is widely shared, and a vigorous application
of Occam's Razor might help the XML world immensely. For example, look
at the XML Schema specification's "particle constraints" in
Section 3.9 and the non-normative attempt to explain this to ordinary
mortals in Appendix H. This seems to cry out for a trip to Occam's
Barbershop, and the neater, cleaner spec that returned would be much
less intimidating for non-specialists.
But simplification is not just a matter of slicing off everything
that's complicated; XSLT is not at all trivial to learn, but it is
immensely powerful once you wrap your head around its paradigm. For me,
this suggests that the W3C Recommendations should be treated as a common
starting point, not "cast in stone" standards. One objective
of us as definers, implementers, and users of these specs should be to
identify what is elegant and powerful, and what does not add enough
value to justify its weight in complexity. The Internet mania for
systems slapped together with time-to-market as the most important
requirement helped create the current mess, and the post
".bomb" mindset just might be conducive to a cleanup effort.
Speaking of Peter Chen, I'd also like to see the XML community become
more integrated with the overall information technology community. For
example, XML data modeling approaches have been based mostly on
SGML-based techniques with their roots in language scholarship and the
legal profession, and which are unknown to typical IT workers. Peter
Chen has been showing the applicability of his Entity-Relationship
modeling techniques to XML data by means of XML tools such as XLink and
RDF. More generally, formal XML processing models ("algebras")
tend to take the structure of XML data as a starting point. This is
antithetical to the relational data model, which stresses "data
independence" and is based on a formal algebra that explicitly
ignores the physical ordering of rows and columns. I hope that the XML
community can meet the mainstream IT community at least halfway, e.g. by
coming up with rigorous but useable formalisms, methodologies, etc. that
preserve the benefits of today's RDBMS-centric paradigm while extending
it to handle the hierarchical and embedded relationships that XML
handles easily.
Please direct and comments or questions regarding this interview
to marcom@softwareag.com
Intellor
Group Interviews Mike Champion on the future of XML