Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] human interaction with XML
 I spent a lot of May at XML-related conferences, first XML Europe and then Open Source Content Management (OSCOM, http://oscom.org). Both conferences assembled a diverse group of people, from programmers to managers to users looking around. Both conferences explored a lot of things that have been done with XML and could be done with it, and I was surprised by how XML seems pretty well assumed in presentations at OSCOM. Something seems to be changing, though, at least in the questions and conversations I'm hearing, not to mention the occasional keynote. XML has succeeded in becoming ubiquitous, but a lot of people are looking for better ways to deal with the vast volumes of information that are now accessible to them. For some projects, the XML processor + application consumer combination is all they'll ever need, and I think the original "XML spec -> XML processors, XSLT spec -> XSLT processors" kind of vision has mostly given us results that make people working on these projects happy. There seems to be a lot more concern expressed recently about projects where people need to interact with information on a regular basis, and where processing may be a multi-step mix of automation and human interaction. Some of the issues are pretty plain, things like the need for a DocBook editor, while others come from people who want to do things like intervene in automated processing under certain (sometimes error, sometimes not) conditions. These concerns seem to apply to development at pretty much all levels of work. I had a long conversation about character entities and XInclude at OSCOM, as well as conversations with people longing for friendlier human interfaces to RDF, SOAP, DocBook, and XSL-FO. The frustrations seem to lie in the gap between the computer-to-computer communications that have become a staple of XML processing and the continued desire of humans to play roles in that process - as information creators, consumers, editors, and mediators. I didn't hear tremendous outrage - it was more like growing frustration. People have grown comfortable enough with their tools that they know their limitations now, and there's a blessed absence of "I expected XML to magically solve my problems". A lot of people looking for tools hadn't heard of particular solutions, but there are still a lot of times when I certainly didn't have an answer for a problem. At any rate, it seems like we could enter a new phase in xml-dev's mission of "supporting XML implementation and development." Perhaps it's time to look around at how this list can help developers with their current interaction problems, much as it helped earlier developers with their needs for parsers, processors, and explanations. Personally, I'm going to spend what time I can this summer focused on the many problems of entities, and building tools which help users cope with things like missing entity declarations and the need to preserve (or re-insert) entitity references when processing is complete. I have a program-accessible foundation and a workable command line, but feel that more user friendly approaches are necessary. While I'm still working in the plumbing, I'm hoping to make plumbing a more pleasantly interactive business. Maybe focusing more on human interactions with XML could let us leave behind some of the permathreads centered on automated processing, notably the namespace ones. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com -- http://monasticxml.org 
|
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
|
|||||||||
