[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ubiquitous XML?
two christmas' ago i got a box set of black & decker versa pack tools. cool set. there are five tools in the box. over the past two years i've used four of the five. i don't feel guilty about not using the other one because i have yet to find a job for which it is appropriate. the same way with xml - just because there are all these way-cool tools that come in the box doesn't mean that i have to use 'em. i don't use multiple inheritance in c++ either. of course most of my coding is done in MFC which puts a big damper on that sort of thing but still, it isn't a tool that i use. that doesn't mean i can't be productive in c++, i just choose not to use all of the complexity that is offered. xml is simple. schemas are pretty darn cool, namespaces are pretty darn cool. XSLT is way-cool. i don't use 'em all and even when i do use them i don't always use all of their capabilities. i do what i need to in order to get the job done and to get it done in a manner that is easy for whoever comes after me to follow. chris makes very good points below. i second them with my additional verbiage above. rjsjr > -----Original Message----- > From: Chris Lovett [mailto:clovett@m...] > Sent: Thursday, November 16, 2000 11:55 PM > To: 'Simon St.Laurent'; XML-Dev Mailing list > Subject: RE: ubiquitous XML? > > > Yes after reading this I have a couple thoughts. > > 1. XML is not a passing fad. It is here to stay, despite all the > weird and > wonderful things we are all building on top of it. XML is simply the > standardization of an incredibly powerful design pattern that has existed > for eons and will continue to exist for lots and lots of reasons. The > standardization of this design pattern is a hugely powerful thing creating > all kinds of new opportunities from PDA to Mainframe and everything in > between. > > 2. The true genious behind simplicity is when it does not limit > the complex > from being possible. This is the balance we must all strive for as we > continue to drive the evolution of XML and it's related family of > technologies. > > 3. Sometimes the most valuable tool in software development is the garbage > can. When a given solution doesn't stand the test of time, then > be honest, > put all politics aside and start over. > > > > Chris Lovett > Product Unit Manager > Web Services > Business Application Division > Microsoft. > > > -----Original Message----- > From: Simon St.Laurent [mailto:simonstl@s...] > Sent: Thursday, November 16, 2000 7:37 PM > To: XML-Dev Mailing list > Subject: ubiquitous XML? > > > This may prove to be one of those messages people with allergies to "XML > politics" delete, but it may not. > > I just got back from XMLDevCon 2000, which went pretty well. I got solid > questions from the audience, got to meet yet more incredible XML folk, and > generally had a good time. I left with a lot of questions about XML's > future, though, and I'm not sure there are any good answers. > > My background before coming into XML was in hypertext and eventually Web > development, where I'd marveled at the way Web development seemed open to > virtually all comers. Though there were certainly different levels of > virtuosity among developers, no question, it was also possible for someone > to learn HTML from a single-page cheat sheet and a ten-minute > introduction. > (I learned from a 116-page book, personally.) > > When I first encountered XML, it seemed like it had the same > potential. It > was, after all, a simplification project, and well-formedness offered > newcomers a quick path to creating documents. XML: A Primer weighed in at > 340 pages, heftier than 116, but a lot of that was examples along > with some > dreaming. > > A simple and approachable XML seemed to offer the world a chance to move > beyond design-by-committee, making it possible for smaller > organizations to > develop customized vocabularies which fit their needs very well without > precluding eventual extension. On comp.text.xml I even suggested that > those closest to documents - secretaries, assistants, and others who were > thoroughly familiar with information in its everyday instances - might be > better-equipped to handle modeling this information than the experts, at > lower cost and perhaps more effectively. (This didn't receive an entirely > warm reception, of course.) > > As time has passed, I've had less and less hope for this vision. Not > because of the familiar claim that 'data modeling is hard', but > because the > supporting standards for XML seem intent on growing more complex and more > obscure simultaneously. While notations and unparsed entities took a lot > of figuring out, they could be safely ignored for the most part, and XML > could generally be pared down to elements and attributes and content if > necessary. > > The new generation of supporting standards requires a lot more > understanding. "Post-schema-validation-infoset", "qualified name", and > "XPath node-set" aren't optional features for developers who want to use > the XML the W3C seems to be excited about developing. My attempt at > explaining namespaces in one hour at the conference proved more tortured > than I expected - live audiences make all the assumptions I've learned to > suppress, and it quickly became clear that the complexities still live. > > This isn't all bad - there is a crew of experts who understand > these things > inside and out, but it's taken even this crew over a year to really dig > into the implications of the Namespaces spec, and this crew is relatively > small compared to the hordes of people who would really like to use XML, > not to mention the folks who haven't yet heard of it but might gain by > using it, even modeling their own information. > > I'm sure there are some folks out there who see this as a good recipe for > making money. The confusion over XML has probably helped sell more than a > few of my books, and certainly contributes to consulting fees which still > seem to be climbing. Schemas are complex enough that I generally > recommend > that people hide them behind tools, and pray that those tools are always > available every time the Schemas need to be explored - there's money there > too. > > On the other hand, I'd like to suggest that it creates a bottleneck, > keeping XML to a much smaller group of people, limiting the economies of > scale available by raising the bar for entry. The existence of > complex and > powerful specs has a tendency to make certain classes of people believe > that they need the biggest most powerful tool around, and there isn't a > whole lot of room to propose alternatives while remaining even vaguely > capable of interoperating with the bloatware community. > > I'm not sure there's a way out of this, since so many people seem intent > and sincere in their belief that 'bigger is better, and tools and experts > will make this workable'. I'd still like to think that there's some room > for 'small is beautiful, and tools and experts obscure as much as they > assist'. While 'bigger is better' may help the sectors where > that rule has > generally held, it doesn't do much for the rest of the world. > > It seems to me that companies developing projects with only the > Fortune 500 > in mind have as much potential for helping the world as Boo.com, and that > the current run of buzzword-compliant tools can thrive only if complexity > keeps organizations with clearer and smaller visions from > competing. Maybe > Microsoft will bring XML to every desktop, but I'm not sure that's a model > too many people (outside of Microsoft) see as a good solution either. > > To some extent, I feel like the moralist critiquing today's fleshpots and > extravagance while promising only a threadbare alternative, a life of > simplicity that offers more by offering less. At the same time, > however, I > think that a more thorough examination of the different communities and > potential communities of XML users would be informative, maybe even > enlightening. > > Any thoughts? Does the path to ubiquity run through the Fortune 500? Or > does it run through the thousands or millions of individuals working on > projects? (Both is an acceptable answer, of course, but inflicts its own > costs.) > > Simon St.Laurent > XML Elements of Style / XML: A Primer, 2nd Ed. > XHTML: Migrating Toward XML > http://www.simonstl.com - XML essays and books >
|
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
|