[
Lists Home |
Date Index |
Thread Index
]
Sounds very positive.
It is quite common for corporate IS types, and departmental stakeholders, to design three-gear solutions, then set up patchworks of exception processes and ever more fragmented databases to bypass the resulting paralysis. (I've wondered cynically if this isn't really just a way for a bureaucracy to justify additional expenditures, but I digress.)
Isn't saying "...continued desire of humans to play roles in that process", a bit of an understatement? Clearly many people do want to communicate across their cubicals and between their toolsets. They get out of one (tool) box, only to land inside another box. Reminds me of the hype I've been hearing regarding model based development - and a misplaced emphasis on building models, rather than model building as an exercise, subordinate to the work at hand - work done by people, for people, not for machines.
- Mitch
Simon St.Laurent wrote:
> 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.
>
|
