[
Lists Home |
Date Index |
Thread Index
]
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
|
