xml-dev - RE: power uses of XML vs. simple uses of XML

[Michael Brennan <Michael_Brennan@Allegis.com>]

This post sparked a very interesting thread, and I can't resist adding my 2
cents.

> There's always been a disconnect between the 'XML core', with its
> inheritance of SGML best practices, its close attention to
> new work at the
> W3C, and the larger body of developers learning XML and applying it in
> their own work without any special fondness for XML per se.  I wonder,
> though, if that disconnect will grow as we pile more and more
> ideas on top
> of what was already a fairly complicated specification.
>
> [...]
>
> I occasionally hear claims that "they just don't understand",
> but I think
> there's something a lot deeper than that going on.  What
> exactly, I'm not
> sure, but I suspect that practice will differ from best practice will
> differ from specification in a lot of unexpected ways over
> the next few
> years, and likely because of this disconnect.

I think there is a gulf today between the 'XML core' and the broader
development community, and that gulf is widening. Most of the developers
using XML don't care about XML or standards; they just need to solve a
business problem. This will never change.

In the realm of data exchange before XML came along, developers either used
EDI standards like X12 or they used proprietary formats and custom programs
to handle them (usually something simple like tab-delimited or fixed-length
columns). The latter was orders of magnitude more prevalent. There were
plenty of people saying the whole world should be using X12 (or EDIFACT or
whatever), but few did because the barriers to entry were too high. The
standards were too difficult to understand for novices and too difficult to
implement. Available applications were expensive. So most IT shops simply
wrote custom point-to-point interfaces, usually low-tech scripts shuffling
files around via FTP.

Today, most developers using XML are still just trying to solve business
problems. They are still writing simple low-tech point-to-point interfaces
rather than buying expensive middleware products. But more and more of them
are using XML for one simple reason: it's easy to understand, and it's easy
and cheap to implement. XML is an easy sell for these reasons. To try to
convince this same development community that they should use Schema,
Namespaces, and all the other things being added is simply a lost cause.

I think that the groups advancing XML standards are not in touch with the
needs of this broader development community. I think the proposed Schema
spec is an example of this. A simple Schema core, something like RELAX,
would be widely used because it provides value and is easy to learn and easy
to implement. When a standard is exceedingly complex, it doesn't matter how
much benefit it provides. The broader development community will simply turn
away from it and seek a more expedient solution. Even if cheap or free
applications are available that can handle these more esoteric standards,
this will not fully address the problem. Having an application that handles
this stuff doesn't absolve the user from having to learn the concepts. The
learning curve has to be taken into account, as well.

I don't see why we can't have tiered standards: simple "core" specs that are
approachable to this broader development community, as well as additional
specs or "standard extensions" that address the more esoteric needs of the
'XML Core'. I know that this would make my life easier when I have a
customer that wants me to accept data from them in their own proprietary
format and I make a pitch to them to send it to me as XML instead. It would
be nice if I could also give them a schema that they can understand and make
use of without spending a large sum of money or embarking on a major course
of study. If I can't do that, then most of them are not going to be willing
to use a schema.

For our customers who have -- or are planning to -- invest in middleware
that handles all of this for them (and have invested the time and effort
into understanding the concepts), no problem! We send them the schemas, and
they are happy. For the far more prevalent customers that are not at that
point, we try to provide an easy to learn and simple to use toolkit for
sending us data in XML format -- a toolkit based on freely available open
source software. My fear is that XML is going the way of the old EDI
standards. Will we see the day when only expensive commercial middleware
supports all of the relevant standards? Alternatively, will we see the day
when open source solutions are available that support the specs, but it
takes a major course of study to understand the concepts and be able to use
the solution? Either of these outcomes will ensure that the standards simply
don't get widely adopted.

Sorry about the bandwidth, but I just felt compelled to add my 2 cents on
this.