OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Web Design Principles (was Re: [xml-dev] Generality ofHTTP

[ Lists Home | Date Index | Thread Index ]

On Mon, 2002-01-28 at 13:35, Paul Prescod wrote:
> > I'm constantly amazed by how different expectations for computerized
> > processing of invoices or orders are from expectations for human
> > processing.
> > 
> > Humans processing faxed or mailed documents are quite capable of
> > recognizing different fields in forms even when they arrive on different
> > stationery or different languages, and can even pick up the phone and
> > make an inquiry when there is a problem.
>
> Sure. But for most companies the point of computerizing is to avoid this
> expense!

That's one aspect of it, certainly.  I don't think it's unreasonable,
however, to suggest that reducing that expense (and getting a system
with more flexibility) is preferable to eliminating that expense (and
getting a system with very little flexibility.)

> >...
> > I've hoped for a while that XML's flexibility might lead to the
> > development of approaches which balance or even combine human and
> > computer processing of information, combining humans' extremely flexible
> > interventions (aka "teaching")  with computers' highly efficient
> > performance of repetitive tasks.
> 
> It does, if you look at it in a particular way. Humans "teach" computers
> to recognize new XML structures by writing transformations from the new
> structures to the old ones. There are many big businesses that this can
> become a mainstream activity through "visual mappers".

Sure, and 4GL was supposed to take care of all of that.

I'd like to see such work done in a much more widely distributed style
taking advantage of the human networks organizations already have. Many
of the reasons for centralization are dwindling, as the price of
computers drops and the need for dedicated programmers slowly lessens.

> > I can't say I've seen this notion taking hold on any large scale, though
> > every now and then I hear of encouraging bits.  I don't believe this
> > problem is technical, however.  It seems harshly cultural. Programmers
> > are deeply loathe to admit that users might have a greater role than
> > use, and that regular human intervention in the very logic of a data
> > structure might have advantages rather than disadvantages.
> 
> Businesses hire programmers to automate things. Most human beings do not
> want to be involved with any process that can be done by a computer. So
> the businesses, the users, and the programmers all consider the system a
> failure if there is a requirement to bring in a human being to clean up
> a computer's mess.

That's very true, and deeply conventional.  I come from a
non-programmer's perspective, however (history major turned media
studies turned Web developer turned XML hacker), and have to say that
conventional view is astonishingly limited. That perspective feels to me
like the old cold-room view where computers are shrines maintained by
priests.  Useful to some folks, I guess. 

Maybe it's time to kick the programmers and the businessmen out of the
room for a few years so that some new ideas have a chance to get started
- or maybe the development I'm watching for will simply have to start
underground.  That's reasonably traditional.

> Having computers and humans working together is great. But you seem to
> propose that users should be required to handle the exceptional cases
> that computers handle poorly. I'd suggest instead that the users would
> rather work with programmers (or visual mapping tools) to automate away
> those exceptional cases so that they can be freed up to do creative
> work.

I'm not sure what creative work you're asking of invoice clerks.  The
"freed up to do creative work" line often involves unemployment, if
that's what you mean.  

And visual mapping tools could be part of such human "exception
handling", adding extra mappings so that exceptions become less
exceptional.

> Also, I notice that some people make a distinction between
> well-formedness and validity when it comes to this issue. Aren't they
> the same? Couldn't we say that if a purchase order comes through that is
> not well-formed it should be routed to a human being who looks for the
> missing angle-bracket and inserts it? It isn't a job I want to have but
> if you're serious about being liberal in what you accept...

Sure thing.  I do it all the time, and I'm pretty amazed at how weak the
tools are for dealing with such errors.  It seems like something
computers should be capable of doing... but aren't.
 
-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS