[
Lists Home |
Date Index |
Thread Index
]
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@cardiff.com]
[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?
|
