Re: Web Design Principles (was Re: Generality ofHTTP
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format