ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
Re: [xml-dev] Web Design Principles (was Re: [xml-dev] Generality ofHTTP)
by Simon St.Laurent other posts by this author
Jan 28 2002 7:52PM messages near this date
Re: [xml-dev] Web Design Principles (was Re: [xml-dev] Generality ofHTTP) | Re: [xml-dev] Web Design Principles (was Re: [xml-dev] Generality of HTTP)
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


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 
Thread:
Bullard, Claude L (Len)
Mike Champion
Paul Prescod
Paul Prescod
Mike Champion
John Cowan
Simon St.Laurent
Mike Champion
W. E. Perry
Al Snell
Gavin Thomas Nicol
Al Snell
Gavin Thomas Nicol
Paul Prescod
Gavin Thomas Nicol
Paul Prescod
Simon St.Laurent
Mike Champion
Simon St.Laurent
Gavin Thomas Nicol
Paul Prescod
Gavin Thomas Nicol
Simon St.Laurent
Gavin Thomas Nicol
Simon St.Laurent
Gavin Thomas Nicol
Jeff Greif
Gavin Thomas Nicol
Simon St.Laurent
Paul Prescod
Simon St.Laurent
John Cowan
Sean McGrath
Mike Champion
Paul Prescod
Gavin Thomas Nicol
Simon St.Laurent
Paul Prescod
Mike Champion
Gavin Thomas Nicol
Mark Baker
Gavin Thomas Nicol
Mike Champion
Paul Prescod
Gavin Thomas Nicol

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved