Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Tue, 2002-01-29 at 01:35, Mike Champion wrote: > > [...much great stuff...] > > But on the other hand, and I *think* this may be what Simon is > getting at, I wish that more people appreciated that XML allows a > middle path between totally mechanical processes that machines should > perform and totally heuristic/artistic processes than only humans can > perform. If you have nothing but "data" -- bureaucratically approved > specifications, automatically generated data, machines as the end > users -- the conventional approach works well. But if you have a lot > of humans in the process -- changing specs, devising new business > models, making sense out of weird data, or consuming the result -- > the XML-centric design pattern can be very powerful. That middle path is precisely what I'd like to see more seriously. Right now it seems quite empty. I stumbled onto this path years ago while pushing my day job into a computer and working on hypertext projects at night. In both cases I had to work to achieve an efficient balance between the work the computer did and the work that I (or other humans) did. I found the work I was doing in databases frustrating because there was no way, for instance, to intervene in a report outside very general parameters or leap outside a table structure the two times it was necessary, while the hypertext let me create a mess too easily. When I encountered XML, it seemed like it offered a better way to negotiate this path. Well-formedness as a foundation meant that I could get my content in and out of various programs, but the structural flexibility meant that I could work on information in forms that made sense to humans, not just relational databases. Modifying information between processes is another enormous gain. I'm still working to create tools for this middle path. Regular Fragmentations is one aspect, helping to create markup from lexical expressions humans find more convenient than angle brackets. MOE is a next step, as a key part of the design is a Swing interface that provides for human intervention in filtering processes. (I hope to evolve that interface into a tool for automating such intervention.) These are just the barest of foundation, but I hope eventually more tools will accumulate and integrate into a useful collection. In the meantime, I continue to marvel at people who assume that the bureaucratic and the artistic should never and will never meet. It may work for them, but I think there's an enormous opportunity we're missing. (One of my favorite examples of such a meeting in the "real world" is the verso (copyright) page of Dave Eggers' "A Heartbreaking Work of Staggering Genius". Take a look if you have a chance - I think it's at least proof that bureaucratic data doesn't have to be dull. Warning: those who like their data pure sometime take offense.) > The response > "make the humans play by the rules of sound engineering" won't work > if you don't have the authority to make them behave, or your > competitors have the ability to deal with them as they want to be > treated. Sound engineering is good stuff, leavened with a dose of human process. Engineers working on physical projects often have to take their human workers into account and give them responsibility, painful though it may seem to those of us used to issuing precise instructions to microprocessors. XML seems to me like an opportunity to worry less about how badly humans behave and take more advantage of their capabilities. We may not love typing in angle-brackets (and computers can reduce that pain substantially), but we're damn good at pattern-matching, communications, and creative thought. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
|
