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 17:13, Paul Prescod wrote:
> "Simon St.Laurent" wrote:
> > 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 know a guy whose job it was to deal with these variant structures. So
> it does happen. But he considered it the worst part of his job. He hoped
> to move to XML so that he could encourage producers to produce reliable
> data by providing a schema.

Was he a programmer, trained to loathe variant structures, or was he a
clerk, used to processing a wide variety of incoming information? 
They're pretty different mindsets.

> > 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.
> 
> They can do real accounting instead of staring at mangled XML documents
> trying to figure out why the elements are wrong. Or they can join the
> support line and help people trying to send documents to make valid
> ones.

I'm not talking about shipping "mangled XML documents", though that
might be the perspective of someone whose notion of conducting business
means standardizing all correspondence by committee.  I'm talking about
dealing with documents that come in on a regular basis in regular form
that aren't necessarily identical for every participant.  

If you've seen a particular form before, you can deal with it - or your
computer can.  If you haven't seen it, you may have some extra steps to
deal with (in your terms, definining a transformation) and then you can
go back to whatever you do.  

I'm not sure that "real accounting" (or the support line) is necessarily
more creative or dignified than managing the communications flows at the
heart of an organization.
 
> Well, the tools are out there to do this. I don't think businesses will
> deploy them in the way you want for a variety of reasons. Once you let
> your business partners know that you will accept non-conforming junk,
> what incentive is there for them to provide you with good data? I guess
> you could bill them for ever order you process by hand...

Have you ever worked in a business that runs on paper documents?  Seen
the odd variety of order forms and invoices that humans deal with quite
handily?  I guess we could have written it off as "non-conforming junk"
but I'm not sure we ever would have gotten that far.  Standardizing the
crap out of business practice and stuffing it into computers sounds like
a game with a very limited long-term payout.
 
> If the XML community creates a new job description of "business document
> markup fixer" then I think we'll have done the white-collar working
> class a great disservice. A person who "helps" the computer to analyze
> variant documents will be a component of the system in a very
> dehumanizing sense. They will likely be expected to deliver
> computer-like turnaround times and extremely high levels of accuracy.

I think you have to get over this notion of varied as inherently
broken.  

XML seems to me like a great opportunity for reconciling the flexibility
of human-to-human transactions and the received brittleness of
computer-to-computer transactions.  You appear to see it only as a
lubricant for brittle computer-to-computer transactions.
 
-- 
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