Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] stop programming, start integrating
 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
