Cart
[Home] [By Thread] [By Date] [Recent Entries]
We call that import and export. We need: 1. You choose a file format. Comma-delimited is fine. XML is fine. That is configurable. 2. We will choose a location. If you like, that is configurable. 3. It must obey our schema. We won't extend our schema for you for less than nZeD$. If the receiving system can't decipher it, that is not our problem. It the two system schemas are semantically incoherent, that is not our problem. This is not configurable. Otherwise, pick a file format. If you want to, we enable you to write the import/export definition files but you have to know SQL, Foxpro, etc. That is negotiable. Conservation of complexity and conservation of ugly are the same law with different names. len -----Original Message----- From: Micah Dubinko [mailto:MDubinko@c...] [side note: Another variant is also widely in use: process A deposits an XML file in a well-known file system location; process B reads, handles, and deletes the file. Call it XMLbaton.] Are there aspects of Web Services that should be this simple, but are being made more complex only in order to satisfy the principle of Sustainable Complexity?
|
