xml-dev - stop programming, start integrating

["Simon St.Laurent" <simonstl@simonstl.com>]

Recent discussions about XML, SML, 'script kiddies', 'hacksaw surgery', and
the potential - not yet realized - for making things simple have left me
really wondering.  

XML has opened up some possibilities that are both intriguing and genuinely
dangerous - though more dangerous to the professional programmers than to
novices.

It seems like XML parsers are supposed to be handy tools that can be
plugged into programs without extensive thought.  I've said at any number
of conferences that I no longer call myself a programmer - I call myself an
integrator.  As an integrator, I take lots of work done by other people
(open source if possible, since it's easier to fix or customize if
necessary) and connect it to make my own projects take form.  There's
always a core bit of application logic that I get to write, but that core
is smaller and smaller and smaller all the time.

The perspective I have as an integrator is dramatically different from the
perspective I had as a developer, however.  I don't want beautifully
complete tools that represent a particular programmer or company's vision.
I don't want extra options that cause interoperability problems. I don't
want to have to deal with components that claim to be the same thing but
really aren't. I don't want 'Fix in Documentation' kinds of problems.  

I expect the applications I build to be working with applications built by
many other people along similar lines, but I won't have any control over
their development process.  Since I may be using XML to get info in and out
of my little NT box and Joe's got Linux, Josie's on a Mac, Jim's got an
AS/400, and Judy's running an S/390, talking everyone into using my code
doesn't make sense.

I want off-the-shelf parts that fit together without extensive pushing.
The simpler and more generic we can make XML and its supporting standards,
the better.  To me, too much of the XML discussions revolve around
programmers' concerns, making it the 'best' standard, not the most easily
integrated.  The 'gotchas' in the XML 1.0 and Namespaces in XML
recommendations may not matter to document authors or parser developers,
but they can make an integrator's life hell.

I'd like to see XML used in a ubiquitous way.  That's going to mean
integrating it with a lot of other application parts.  What we have now is
a start, but we're a long ways from the simplicity that gives tools like VB
the power to deliver a real (if slow) application without requiring
developers to build everything from the ground up.  Professional
programmers shouldn't be necessary to use XML, and neither should XML experts.

It'd be nice to think that users, including 'script kiddies' and VB and Web
developers, can stand on the shoulders of the XML core community without
having to call us up all the time to ask why things don't work, what things
mean, or how they can make their system speak XML.  It's a bit of a dream
right now, but it hardly seems impossible.  It'll take a change of
attitude, for some a change of business model, and possibly - eventually -
a change in the way the core specs are built.

Okay, enough dreaming.

Simon St.Laurent
XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)