[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: power uses of XML vs. simple uses of XML
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.
|
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
|