"Simon St.Laurent" wrote:
>  
> ...
>  
>  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.

He was not a programmer at first (technical writer) but he became one.
The problems had to be successively automated away so it had to be
handled by someone who new how to teach computers to automate tasks.
Which is the definition of a programmer's job. His macro evolved into
the most hideous Perl script you've ever seen. And eventually they
started to push standards for input back to their information suppliers
because the increasing complexity of the system was causing errors.

> ...
>  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.

Here is how I would structure purchasing at a business I would own:

 1. Accept XML in all of the most popular purchasing formats: ebxml 2,
biztalk 3000, etc. etc.

 2. Supply a web form for those who cannot generate standardized XML.

 3. Supply phone and fax numbers for those who cannot use the web.

That would buy me compatibility with every consumer on the planet
without forcing non-programmers to become variant XML de-cryptogrophers.
If a human being on my side needs to be involved anyhow then it is not
clear what value I'm getting out of XML for that transaction. Why not
have the customer use the Web form?

>  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 would predict that this "dealing with it" is really hard. Really,
really hard. The element type names may be cryptic. You may set up a
transformation that does the wrong thing when a new document comes
through. etc. What technology do you envision that will make this easy
in the future?

>  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.

That's a romantic way of putting it but there are hundreds of jobs that
allow a person to be involved with the communications flows of the
company. We don't have to invent a new one.

> ...
>  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.

Do you mean to say that a company that does NOT accept variant XML input
will lose business?

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

Variety is perfect for systems managed by humans. Conformity is better
for systems managed by computers. Having computers "kick out" bad
documents and forcing humans deal with them is what is broken. It puts
the human at the mercy of the system and shifts the burden of generating
appropriate data from the producer, where it should lie, to the
consumer, where it should not. If you provide the producer with easy
ways to generate proper data (e.g. a web form) then why wouldn't they
conform?

>  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.

Not at all! XHTML, XForms and Jabber are three good examples of XML for
human-to-human and human-to-computer transactions. But the nice thing
about them is that the human doesn't need to know XML and the computer
doesn't have to deal with structures it doesn't recognize. Each does
what it is good at. Interpreting XML is, in my opinion, a job best left
to a computer.

 Paul Prescod

-----------------------------------------------------------------
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>