[
Lists Home |
Date Index |
Thread Index
]
On Tue, 29 Jan 2002, W. E. Perry wrote:
> I have been automating transactions since 1979.
I've been... breathing since 1979, and alive since 1978!
> For any particular transaction
> type, I work myself (and those who work with me on the project) out of a job
> in no more than a matter of weeks, or at most, months. We do not do ourselves
[snip]
> them competitive and in business. The clients cannot quit innovating in order
> to immerse themselves in the drudgery of transaction processing, and
> particularly not to work out the exception handling--that is what they hire me
> for.
Indeed.
1) If it can be automated, automate it (unless it's something you do so
rarely that it's not worth the cost of automating, of course).
2) We've been trying to standardise data interchanges for a while now. XML
doesn't seem to have anything in it that will intrinsically make this any
better. At best, the sudden interest in data interchange from IT managers
that XML has brought about might be used to bootstrap inreased awareness
of the problems of data interchange.
3) A lot of data interchange works pretty well: Look at GIF and JPEG
files, ZIP files, filesystems (from ISO9660 down to the lowly FAT floppy
disk), ASCII text (I wouldn't call anything beyond ASCII 'working well',
although UTF-8 is getting there!), RTF, HTML, CSV, MIME, and so on. Large
scale data interchange isn't really *that* broken; it works quite well
already. There's more of a problem of people not having Microsoft Office
than malformed files flying around.
4) Setting up a communication between two private parties is harder, since
it requires cluefulness on both sides, rather than just cluefulness
existing in the industry as a whole and de facto standards emerging out of
people recognising that cluefulness or the benefits of it. However, for a
very reasonable fee, myself or many others like me will gladly gather
requirements from all parties involved and design an extensible
interchange specification (note *specification*, not just *file format* -
there's lots more to it than the file format) that can be codified into a
contract for parties engaging in the communications.
5) XML-DEV troll: Binary file formats are less likely to be mucked up than
text ones because nasty humans aren't getting silly ideas in their head
about hand-editing them! Sorry, couldn't resist.
6) When a data format problem occurs, it will usually require some kind of
specialist knowledge to fix it. The simple cases can probably be fixed
automatically as easily as they can be fixed by non-programmers. I mean,
differing element names might be handled by a human as long as there are
the same fields with the same basic content - but referring to an online
thesaurus will probably allow the software to automate this anyway. What
I'm more worried about are variations in the actual semantic models...
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
