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