RE: Principle of Sustainable Complexity
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?
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